IPython is a python CLI with attitude and a really nice set of features like completion. Eitan's used it in accerciser and  I'd like to see in the Wing debugger. Anyway here's a set of useful introductory videos by Jeff Rush

and the first edition is free .

I read most of it on the plane back from Boston and it's pretty good with plenty of code examples covering a range of topics. I could have done with the articles on custom pyGTK widgets and ElementTree a month or so ago and still found them useful having worked out most of what I needed.

I'm planning to submit an article of python use in accessibility .

I'm just back from the summits and in an attempt to stay awake on the train from LHR to Exeter jotted down this summary. I hope I didn't forgot anything important. Here's the 'offical' report on the Gnome wiki.

My overriding impression from this years summits is how far we've come since last year and how focussed and effective the accessibility teams are. That may be partially as I'm not such a newbie now but it is undeniable that real progress has been made. It was great to see several new faces as well having the chance to catch up with old friends from last year and from IRC. Once again the face-to-face provided invaluable in resolving issues and moving open source accessiblity forward by a large increment (for example Atilla from Nokia reminded to look at their Hildon input method for Jambu). The a11y group really create a buzz with their passion for creating the best possible solutions for users with few distractions, something that really impresssed at least one of the new comers. Mozilla continues to play a critical central role by funding activities in many of the projects and acting as a central independent facilitator working with Sun, IBM and volunteers.

Mozilla's summit was hosted at WGBH, the PBS affiliate who are very active in accessibility (they invented closed captioning). Whilst the room was rather too small to offer much flexibility for the 15 odd people present we still managed to have a good meeting organised around presentations and discussions. Aaron kicked off with a summary of where were are, how much has been achieved and what is yet to be done. Mick Curran explained how far the NVDA screen reader for MS Windows has developed and the how current focus is on increasing performance through a module that is injected into the target program and communicates to NVDA (this is called 'in process'), Jorges Torres from Komodo Open Labs introduced this OATS startup company and their project Vocal Gestures which will provide control through non-language utterances. Jorges also demonstrated their software for manipulating in 2 dimensions with a single switch. Vocal Gestures is planed to integrate with Jambu which I described and demoed though the projector would not play with my laptop.

After the Summit Mozilla treated us a to a fantastic meal at the classic Italian restaurant that Aaron and Gijs located in the North End of Boston. This area has an almost continental feeling and was buzzing with activity.

Gnome launched with the briefest of preliminaries after which everyone got down to solve problems. I was surprised that there were less present than at the recent GUADEC in the UK. It seems GNOME is getting something of a European vibe. I recognised several faces in Boston from GUADEC and met a couple of guys from England including Rob Taylor who is a DBUS expert and now boss of CodeThink UK open source consulting company

We headed down to the a11y room where Willie quickly focussed us and reiterated the theme of working on problems rather than 'dreaming' something I think we achieved in spadefuls. Willie kicked off by introducing MouseTweaks in response to a request to get it added to GNOME. MouseTweaks adds useful dwell and delay click features and we agreed to see in gets added, We then decided the subjects to work on and cracked on with it. See this summary on gnome live which explains the progress made with Firefox, Testing, Replacing Orbit with DBUS and magnification.

The second day was much more free form working and hacking in groups. The day started with a collective summary of the previous day's group activities and Willie gave a great description of our work. It is very pleasing how high profile a11y is in GNOME and how the larger community are interested in ensuring the accessibility of the desktop and applications. We promoted accerciser as the tool for exploring and developing a11y and Eitan demonstrated it to an enthusiastic Tomboy team when we heard they were adding custom widgets to it (stock widgets get a11y for free but developers of custom widgets have to add it themselves).

On day 2 Rob Taylor joined us to discuss our concerns with moving from Orbit to DBUS and how ATSPI could be supported. This is a critical issue as the GNOME community have depreciated Orbit (GNOME's CORBA implementation) which ATSPI relies on and so it is really encouraging that a way forward has been found to address with Rob and Ariel working on the port and performance tests.

Google came up trumps and enabled GNOME to offer us an open bar at Flat Top Johnny and after burgers we shot some pool on 4 reserved tables and may be drank some beer. I discovered American Bass is not a patch on the UK original, which when it is on stillage can be the most perfect of ales. Apparently we fell well short of the budgeted bar tab so I guess we'll have to try harder next time.

I spent the final day with Mick Curran, Aaron, Eitan and Kristian and came away with confirmation from Aaron that he was basically happy with where we are going with Jambu. Eitan has also join the project as a mentor and I'm really pleased to have him to help me with his imense experience in LSR, Orca, accerciser and pyatspi. He's already contributed critical feedback and good ideas for our next phase on In app selection and we've hacked on some starter code.

As a I final note I like this post from JP Rosevear on the effect we had on local children. 

A recent article in the Guardian on the need for communications aids and associated support for children's education and basic rights. There's also a new blog post

I've just spent some enjoyable time with the Aptus interactive mandelbrot set explorer and I 'm even going to show it to the youngsters.

A mandelbrot renderer was one of the first programs I wrote on a consumer home PC in Basic (can't quite remember which but probably Sinclair QL) . It took forever to to draw a single image so I soon gave up exploring. Aptus use some C  and numpy to get good speed out of python.

One of those funny little linkup things that make life fun occured here. I found Aptus on Planet Python and looking around the author's site, Ned Batchelder I saw that he was probably on the charity walk that slowed Aaron, Mick and I down when driving around Boston in search of a quick lunch. In Addition Ned has a son with Autism and has written a number of interesting posts. We have a group of friends with teenage children who have learning disabilities and have a created a charity Rainbow Living which is in the process stripping and rebuilding a house for supported living accomodation. 

After the previous false starts in using XUL and LSR this phase concentrated on creating working access to Firefox menus and the web using a simple OSK and switch and with minimal platform dependencies on Linux. This was achieved and it is now possible to use Jambu to browse the web with a toe (thanks to Eitan Isaacson for this observation in his review). A UI is provided that allows navigation around selected areas of Firefox (toolbar, shortcut bar, web document) using 'next' and 'action' buttons. This adds a minimal level of indirection between user actions (on the Jambu cells) and control of the target application (Firefox). However this is still fairly frustrating to use so the next phase will concentrate on in-application selection which will further reduce the indirection.

The result is a 'framework' for creating simple SVG described UIs that consist of a number of 'cells' and which can be operated using a switch or the system pointer (mouse). Very little is 'hard coded' into Jambu with the appearance and behaviour being declared in SVG extended with tags to control visibility and respond to events by calling 'primitive' functions. A minimal 'virtual machine' model has been created that consists of cells which have properties that may be manipulated and that effect the display by hiding or showing sections of SVG. This is is sufficient to provide a control set for Firefox and a basic On Screen Keyboard, while being flexible enough for many other purposes. Control of target applications is via accessibility API (ATSPI) or simulated key events.

An early decision was made to create a framework rather than specifically solving the Firefox control as one of the prime objectives of Jambu is to encourage community input and innovation through providing an easy way of authoring UIs using declarative web like documents. This obviously delays development results and requires effort in supporting the framework and this effort turned out to be more expensive that initial experiments indicated. However the resulting framework is usable and flexible with authoring consisting of hand editing the Jambu file and possibly creating new primitive functions in python.

A number of refinements are required to better meet the goals, in particular there is currently a new expression 'language' to be learnt and which should be replaced with Python or Javascript. Graphics editing with inkscape is not yet seamless as is required to allow designers to work on the visuals in an environment that suits them.  Performance is reasonable but needs optimisation and is untested with complex SVG. Switch input  is semi hard coded and should be abstracted and made part of the file format. More flexible device support is needed as it is currently for USB joysticks only. The warning/error handling needs rationalisation as errors appear on stdout and  can be cryptic.

Several SVG problems were encountered which may be librsvg bugs so these need to be investigated and bugs raised or patches submitted.

Technical appraisal

Jambu has a small set of dependencies; Python 2.5, pygtk, librsvg, pyatspi and pygame. It currently works on Linux but the desire is to port it to Windows. While early experiments proved pygtk is usable on Windows, the critical need is for a pyatspi (or rather a pyia2) for Windows. It is worth noting that pyatspi makes accessibility access from ATs extreamly easy (big thanks to Peter Parente, Eitan Isaacson and Willie Walker).

The basic approach used is to leverage SVG extensibility mechanisms to add visibility control and behaviour (like XBL) to a master SVG document. Jambu loads this and displays and operates the UI in a GTK custom widget. A fundamental constraint is that librsvg is not a DOM so it is not possible to update parts of the document and get automatic display refresh. Rather librsvg will only draw entire documents (actually the default python bindings are missing some functions to draw a sub tree). Thus we need to break up the document into individual SVG documents for each cell using state to decide on the exact contents. The chosen solution was to embed expressions that determine if sections of each cell are visible by being evaluated at display time. This has performance impact and also clutters up the SVG with behaviour so is will be changed to the more traditional setting of visibility properties from code (e.g. the display CSS style).

Another useful feature SVG is that nested SVG tags can use a viewBox for co-ordinate mapping. This allows us to use corse grid co-ords for the location of the cells and high resolution for the cells contents. it also means a cells co-ords are it's grid x,y,width,height without needing to add attributes for this. The nested SVGs get removed when rendering. However this solution is not complete as inkscape loses the grid.

The expression format was intended to be a temporary and experimental place holder until a decision was made to go either fully scripted (document driven like XBL or possibly code driven as in libglade) or fully declarative (ala iHTML). This was a mistake as it was much too expensive to  develop even using Python's excellent dynamic facilities and it also creates a new language to be learnt by authors. It is now clear that declarative code syntax is really unworkable (debugging for one). There are also concerns that Python sandbox is unsafe and Jambu files should be web deployable (so Javascript may be a solution).

Python has proven such as delight to use for this and has no doubt saved a lot of time and code, even though I've been learning it's deeper features. It was relatively easy to use the dynamic features in conjunction with classes and functions being first class objects with flexible construction. I hope the resultant code is not obscure (though it goes deep). It is a little tricky in places and I would redo the use of bound/unbound instance methods in a more pythonic way if this was not going to be depreciated. Decorators provided a neat way to encapsulate argument checking in the cell primative functions, removing a lot of boiler plate code.

I used a Test Driven approach for developing the core parts and highly recommend it. It divides the problem, gives a focus on usage, instils a rhythm and provides reassurance when refactoring. Plus it tells you when to stop coding, when the temptation can be to add 'just one more' feature. When used in conjunction with a debugger and stepping through code TDD provides a high confidence in quality (Ok so some TDD folks say you don't need a debugger). In any case you need unit tests for code coverage and regression. I miss being able to use these techniques for the UI so will probably make Jambu accessible itself and use a test framework like DogTail to drive it.

A personal note

I have really enjoyed this phase though it has been a steep learning curve (gtk custom widgets, SVG, deep Python) and a little pressured to get it all done in time for the summit. Creating something like this from scratch is in some ways harder than learning someone else's platform (even complex ones like XUL) and can be a little lonely and insecure when you're not sure if you're going down the right track. I won't really know until we get people churning out Jambu files for all sorts of use cases (and then some will want a WYSIWYG editor).

I really appreciate the support of Aaron Leventhal and Frank Hecker. Mozilla's funding of accessibility is making Jambu possible and I look forward to the time when users can add their thanks.

Resources

The Jambu file format is described in more detail and issues are discussed in jambuFileFormat.txt.

Details of obtaining and using Jambu can be found in the README  and on the Jambu home page.

http://danbri.org/words/2007/09/14/199

Stephen Elmslie over at OATSoft.org recently asked about Jambu on XUL and as this once appeared to be the perfect platform but one that I abandoned I collected my current understanding of XUL and it's suitability for Jambu.

If I've got it wrong I'd love to know as XUL is a very attractive platform from several angles.

[oats-sig] ASUS mother board good for OATS devices

Steve Lee steve at fullmeasure.co.uk Tue Oct 16 14:12:47 BST 2007 Previous message: [oats-sig] ASUS mother board good for OATS devices Next message: [oats-sig] RE: waking up PC's Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Article: [oats-sig] ASUS mother board good for OATS devices

On 16/10/2007, stephen emslie <stephenemslie at gmail.com> wrote: > Steve: I wonder just how stripped-down that firefox is? While I know > you have been through this in The Real World, I'm still facinated by > the Jambu concept deployed as a firefox extension and leveraging > svg+xbl+javascript+python+bells+whistles+etc (would firefox's > extension mechanism be compatible with Jambu's ideas of > extensibility). Please feel free to put me right though, as I'm > unfamiliar with the practicalities of xul-based development. Here's a quick XUL 101 while I try to get Ubuntu Gutsy installed on a PC whose main Windows disc died. XUL (aka the mozilla platform) is the framework that Mozilla created in order to develop Firefox (typical developers always create a platform first and then solve the original problem). XUL itself is a document-based language that lets you describe Rich User interfaces much like HTML forms and use XBL to define the various 'controls' that can be used. Under the bonnet a set of components provide critical services like machine access and communications in a platform independent way (Win, Mac Linux). These XPCOM components are accessed from core Firefox code in C++ or from javascript through fairly complex boilerplate code (though this may change). Thus you get rich applications that run as native platform processes. An alternative that is gaining great popularity is web (2.0) apps powered by Ajax frameworks like Dojo and running in a web browser. So to write a usable XUL application you have 3 main choices, each with different dependency and deployment tradeoffs. * A firefox addon - only runs in firefox * XULRunner application - separate application process. * WebRunner - a firefox with only a document and without UI (ie. no Chrome as it is called) There are also various versions of XULRunner around like Komodo and several internet TV and Media programs are using custom versions. The community are looking at making it a stable dev platform. As for Jambu, well I was very keep to use XUL with python but the instabilities of python support were the big issue. In addition Jambu is a general AT and must not be tied to a specific application. However the first phases are firefox specific and we always want web deployment and compatibility. Not having a SVG DOM is a major pain and Firefox scores here, though a custom XULRunner build would be needed. So XUL runner application would seem the most usable. A possible architecture giving the best of both worlds would be to encapsulate the core python Jambu (e,g pyatspi access) in pyXPCOM components and use XUL + javascript for SVG UI etc. This has some attractive features and some complexities but there are enough uncertainties in the XUL world to make me think that should wait a while to see what happens. Creating Jambu as a firefox extension without a custom build is limited to what Firefox supports. There are probably issues with making that a general purpose AT as firefox has a security model (though that is relaxed in extensions). I see the areas of most resistance in platform a11y API and control of applications and universal device handling (firefox abstracts a lot). I guess it would be fun to explore what could be done but that is not something I would attempt at the moment. Once we have Jambu reach a reasonable level of maturity then it might be time to review XULs status and see if might be worth while. We'll understand the problem space better then. Cheers -- Steve Lee -- Open Source Assistive Technology Software PowerTalk - your presentations can speak for themselves www.fullmeasure.co.uk

[oats-sig] ASUS mother board good for OATS devices

Steve Lee steve at fullmeasure.co.uk Tue Oct 16 14:12:47 BST 2007 Previous message: [oats-sig] ASUS mother board good for OATS devices Next message: [oats-sig] RE: waking up PC's Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More Information:

More information about the oats-sig mailing list

2003 Becta  |	Return to top

 

The Nokia N810 that Nokia's test lead Attila put into my hands at the Gnome Summit has now been officially announced. Features include the Mozilla based browser (announced at GUADEC), a slide-out keyboard and GPS. There's also some pictures of this desirable little device and a couple of developer viewpoints.

It seems Maemo is now a supported platform in Forum Nokia. The professional support and community exposure should be great news for the public profiles of Meamo, GNOME, Linux and Open Source in general.

The new GTK2.10+/Hildon stack is more mainstream and so now uses Cairo. I look forward to getting Jambu working on it as there some synergy between Alt Access and mobile devices including the Hildon input method framework (and the Hildon Desktop has some Python support). Attilla felt that AP-SPI is more likely to be available if it has a much reduced footprint, something the DBus port should achieve by dropping Bonob. Maybe next year.....

John Berkow leads this Government review.

I am very pleased to have been asked by Ed Balls and Alan Johnson to lead this review. It is the first major review in seven years for people with speech, language and communication needs and it provides an excellent opportunity to bolster support for vulnerable children and young people.

This could lead to improved provision and I hope to see OATS such as the ACE centre's SAW and Jambu playing a part along with research projects such as CCF. We can even hope for increased funding for invaluable services such as the ACE Centres.

 

After a week of fiddling I've got dual screen mode sorted on Ubuntu Gutsy with my NVIDIA GeForce FX 5600XT connected to a Mishubishi 900u and a Iiyama ProLite E481S.

It turns out I only needed to use sudo nvidia-settings which gives a nice GUI for editing xorg.conf (so back it up first). I simply enable the LCD monitor, juggled the poisiton and resolution of the CRT, selected TwinMode and then dragged the Gnome panels to appear on the correct screen (LCD on the left). Loads of space to develop on.

I got distracted by the new  'screen and graphics preferences' which seemed to be what I wanted but got messed up big style. It turns out this is an (imperfect) front for the XRandR X addon that gives hot plugging of displays and only with Intel and ATI Radeo drivers. Still that might be great with my lap top and mean that next time I try to use a projector I might actually get a result. I'll give it a go once I've updated it to Gutsy.

I've no doubt that I'm not the first to dice with death by using usermod, or the last. To my mind it's has a very poor interface design for adding a user to groups. I ended up removing myself from all groups with the result that I had minimal rights and couldn't even run sudo (thank goodness for single user mode and another Gutsy installation to comapare with). By default the -G switch replaces all the groups you belong to. And that is despite the manual page saying:

           A list of supplementary groups which the user is also a member of.

If you scan read you'll probably miss the later sentance that says you also need to also specify -a to get append behaviour.

Ok so it wouldn't be so bad if it did a backup of /etc/group or otherwise provided a rollback mechanism, but I couldn't find one. This is hardly safe behaviour, let alone fail safe (e.g user fails to add the -a).

From now on I'll revert to just editing /etc/group directly, something I avoided this time in the mistaken belief that a command would be less error prone.

Yesterday we had a fantastic family walk around Scorhill in Dartmoor. It was one of those perfect early Autumn days with blue sky and sun counteracting the chill in the air.

In 4 1/2 miles (7.2km) we explored a stone circle, a Toleman stone (with large water worn hole), clapper bridges (horizontal stone slabs), bolders in the young river Teign, the imposing granite block of Kestor rock with its deep water filled rock basin, a 15 century church and a 14th century faux castle, There were also stunning views of open moor, pastoral farm land and deep forest with logging in progress. Wildlife included moor sheep, cows, horses, butterflies and a couple of shiny blue beetles plus various dogs taking their owners for a walk.

All-in-all, plenty of scope to walk, run, climb, scramble, splash, stalk/hide, chase, slip, fall, explore, sing and eat lunch sitting on rocks.

Perfect.

The route: Starting at Scorhill gate nr. Gidleigh (661877), SW to Scorehill stone circle, S to Tolman stone on Teign, W to clapper bridges, SSE to corner of wall, E to Kestor rock, N along ridge to gate and lane, E to RH bend in lane and turn left onto track. NE through forest, down to Teign, over and up, R at T, L past church, L and L back to gate. 

On google maps (for what little it is worth). 

I'm immensely grateful to Mozilla Foundation for making my dreams of developing Accessibility software come true. The Mozilla accessibility grants scheme enabled us to make the decision that I would concentate on the area of work that I felt called to work in but could not quite work out how to do it whilst supporting a family. As a result I'm part of a great community of people working hard to increase the accessibility of the web and ICT in general.

Frank Hecker has posted a summary of MoFo's grants in 2006 including a detailed list of the accessibility work that Mozilla have made possible. In another post Mitchell provides some very large numbers and the big picture of Mozilla's activities, progress and future.

Discover recently announced the winners of their competition to create a video explaining string theory, one of the more abstract theorys of fundamental physics. In addition to being educational it's a good example of how 'amateurs' can contribute real value and energy, as we so often see in Open Source Software and Open content communities.

This year's gorgeous wildlife photos.

I was recently asked by someonce interested in playing with Jambu about

the complexity of the definition/svg file, why didn't you take an approach like onboard's?

As improving the design is something that must be addressed soon and the issues are not specific in my report for Mozilla I offer the following expansion.

Jambu is becoming a flexible framework for creating user interfaces that give first-class access to user who do not use a mouse or keyboard. There are many aspects to this but focusing on those requirements that directly related to the file format:

• attractive visuals using SVG (open standard) which provides for scalable hi quality graphics. Graphics should be editable by designers using standard tools such as Inkscape.
• simple but flexible layout
• flexible navigation & interaction (e.g scanning modes)
• flexible architecture with as little 'hard coded' as possible
• easy to create new applications (initially with web-style techy skills, later WYSIWYG)
  
• web deployable
  

On the other hand Onboard is focussed on being an On Screen Keyboard which allows non-keyboard users to generate keyboard input (at least that's how it appeared to me when I looked at the first release). Thus its XML vocabulary is targeted on specifying 'keys' on a screen keyboard. This allows a simpler document structure by fixing features and making assumptions that Jambu tries to avoid with-in reason.

The 2 example layouts (firefox and osk) don't promote the SVG possibilities as I spent zero effort on appearance and we could really benefit from some SVG bling. In addition the OSK was more an example to implement in order to stretch the platform rather than trying to be a usable OSK. Jambu will integrate with other ATs such as onboard and dasher where they do a specific job well (why re-invent the wheel).

The current Jambu file format is a first attempt at meeting the above goals and rather falls short in some ways. The key features of this version are:

• format is legal SVG using allowed extension mechanisms (namespace)
• cells are arranged on a grid coordinate system using SVG viewport mappings thus not needing extra attributes and still offering none grid like appearances (using fine grids)
• both appearance and behaviour are defined in the file
• a simple 'virtual machine' model of cells with string properties and a simple API for interaction with the outside world (e.g accessibility API).
• different states of the UI widgets/cells are described in SVG using conditions to effect visibility
• behaviour is declared using a specific expression syntax and methods defined as a sequence of steps.

This doesn't meet all the requirements well and critically needs to be simplified (KISS, basic things easy, complex things possible). Areas that need to be improved include:

• the expression format and semi declarative methods need to go as they make debugging hard and the idea of describing code in XML turns out to be a mistake.
• moving the behaviour out to a separate file (implement an Xinclude) and providing default cells/behaviours will help greatly.
• equally having a simple top level layout definition with each cell in it's own file may simplify editing in Inkscape as group editing seems to be a little awkward (the dynamic nature of the cells also creates challenges).
• having conditions evaluated at display time should be replaced with the traditional attribute (e.g. display CSS style) as it clutters the apperance with behaviour. It was an interesting idea fuelled by the necessity of re rendering each cell, but it has a performance impact.

I still think XUL/XBL document-based is a good model to follow rather than a glade-like code-centric approach. Even if it requires a little more support for debugging. Thus I think behaviour methods will have a body of python code as XBL has javascript.

So I'll be raising tickets in the Jambu trac for the work packages but my current contract with Mozilla is to do the in application selection which means I'll have less time for now to work on these issues. Any volunteers?

You can monitor changes with the trac recent pages and there is a RSS feed.

The Open Document Format v1.1 Accessibility Guidelines Version 1.0 are now available for public review.This will help ensure ODF and applications like OpenOffice.org are truely accessible.

Peter Korn and Rich Schwerdtfeger have edited a fantastic introduction to the various disabilities, suitable Asistive Technologies and how to support them in software.