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

Steve: I wonder just how stripped-down that firefox is? While I know

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