It just occured to me that I have not been posting much about Jambu lately which is rather suprising as it is the focus of most of my energy. Thinking about it the reason for this is at least partially that I tend to blog as a little light relief or to get something off my chest or even as a way to make notes. I try to keep posts informative and not too technical. Jambu documentation has it's own place.
I've been testing the suitability of XULRunner with Python as the platform and having now completed a technology tester sample I have taken the opportunity to review the situation. I've decided that XUL is not the way forward. Instead I'm now planning to use LSR, the Linux Screen Reader created by Peter Parente.
Why? Well XUL is an effective platform and has many great features for rapid development of rich applications, especially those with strong internet features. However XULRunner and especially XULRunner with Python is not yet fully supported by the main development efforts, is rather unstable and is missing features needed of a productive development environment. This is set to change but with timescales that are to long for my purposes.
It's become clear that Jambu's strength is to be in providing flexible alternative input device support as well as providing attractive and effective computer access. Handling many differing devices effectively in conjunction with a11y APIs is a complex task and requires a good infrastructure for which XUL has little support.
<stage type="entrance">
<move who="LSR" type="enter" where="left" />
Enter LSR in shiny suit.</stage>
LSR's name is misleading as it is actually a platform for developing accessibility tools and provides a good architecture supporting devices, a11y APIs, dialog based user interface, flexible user configurations and persistance. In fact as I'm learning about the architecture that Peter has carefully crafted I'm getting thoroughly impressed. It addresses several of the issues I've already thought about and I'm sure many more. It may appear fairly complex but I'm getting the impression of good abstractions and high utility without getting in the way of what I want to do. LSR appears to provides much of the needed functionality, leaving the display of an OSK and in application selection. For graphics I plan to use Cairo which GTK and onBoard are already using. In fact I may leverage onBoard, at least initially to get a workable OSK.
One issue is that LSR is currently Linux, GNOME and AT-SPI specific. Personally that's no problem as I relish developing on Linux again (as well as Python), even though it adds some learning curve and thus delay (fortunately LSR abstracts much). While modern Linux such as the latest Ubuntu provide an excellent user experience, most target users and their supporters are using Windows, largely as most programs are still Windows only. While it may seem a good plan to make Linux attractive by having great switch applications, I think changing OS is too big jump and the better approach is to provide a smoother migration path from Windows. Fortunately LSR has been designed with portability in mind though that would be a conciderable chunk of work. While that porting will be needed, the plan for now is to reduce further delay and start on Linux, while keeping one eye on the port to Windows. LSR's architecture and the availablity of IA2 makes it a much simple problem to solve. In addition the fact that initially we're looking at access to Firefox only makes a Linux Live CD or virtual machine image a possible interim (obviously not much use for controlling Windows programs).
A lesser concern is how well Linux, well X, supports USB switches as they are seem to be the most common way of connecting. I haven't yet researched it in detail but I got the impression at the Gnome/Mozilla Summit last year that it was not perfect. It may that we need to contribute some improvements there.
The LSR team is small compared to Mozilla which is perhaps an advantage in that developments can happen fast if people are free. Peter has already proven highly responsive and I know he has very comprehensive experience of a11y, Linux, Windows and Python. I think I'm going to enjoy working with LSR.
So over the next couple of weeks I will be investigating LSR and putting it through it's paces. From what I've seen so far it has all the hallmarks of being a good choice. The delay has been frustrating for all and it's to Mozilla and Aaron Leventhal's great credit that they are being supportive of the delays and this change.
So has my work on XULRunner been wasted? Not at all. It's been an important part of refining the requirements. I have made contacts and contributed to the community, including documents and a couple of bugs. I have gained a huge amount of knowledge about Mozilla technology and operations that will be invaluable when working on Firefox access or Firefox accessibility. My experience has left me even more impressed with Mozilla's operation and how they are embracing their wide community and coordinating everyones energy to create high quality open source software. XUL is highly recommended and many interesting applications are appearing that are based on it (E.g. Songbird, Joost).
Finally here's a list of features I need in a platform. LSR scores well.
* Flexible access to all input devices - gestures across devices
* Good access to any application including via a11y APIs
* Good graphics support, eg SVG and basic UI
* Good support for user customisation - preferably UI, declarative & script
* Good development tools leading to fast development with good architecture
* Interpreted & interactive, Python or Javascript, some C++ OK
* Cross platform - Windows first, then Linux, then Mac
* Easy deployment
* Use common dev skills - attract developers
* Stable and well supported - mature
* liberal licence (non copyleft)
* use open standards
* An existing developer community to tap into would be useful
[Update 1 May 2007]
LSR provides a sophisticated model with many abstractions appropriate for the core requirements of Jambu. GTK and Cairo add support for UI widgets and graphics. Jambu code will leverage the abstractions with little need for direct access to a11y apis or devices. Direct ow-level access is still possible if really required and Python's large selection of extension 'modules' can be leveraged.
Abstractions provided by LSR are:
* Python - the productive 'high level' scripting language is used throughout
* Adapters - abstract the platform a11y api and events
* Walkers - abstract navigation of the a11y hierarchy
* Devices - abstract i/o devices such as keyboard, TTS and braile
* Gestures - abstract device event sequences
* Profiles - organise behaviour for specific purposes (e.g screen reader)
* Tiers - organise behaviour for individual applications (e.g Firefox)
* Perks - collections of related behaviour, execution context for tasks
* Tasks - fundamental unit of behaviour (cf. event handler or function)
* Choosers - pattern for managing UI especially GUI such as dialogs
* TaskTools - API used by Tasks, providing an abstract environment
* Monitors - and logging provide visibility of behaviour
The architectural model is a core Access Engine comprising a number of managers
* Device Manager - devices
* Event Manager - raw a11y (via pyLinAcc), device and abstract LSR events
* View Manager - a11y adapters and walkers
* TierManager - Tiers, TaskTools API support Perks, Tasks & Choosers,
* Registrar - configuration and persistence
and extension 'User Interface Elements' of which a number are provided
out of the box:
* I/O Devices
* Perks, Tasks for specific applications
* Choosers - settings dialogs
* Monitors
The platform abstractions should ease the process or porting to
Windows and Mac. In particular the effort would be focussed in The
Access Engine and Choosers.
