Re: [orca-list] some programmers want to contribute to orca.

Hi Halim, gang,

On Mi, Aug 15, 2007 at 10:53:06 +0200, orca yokoy de wrote:
no, it is not a joke.
AT-SPI is not used by all access technologies.

Which other access technologies you are talking about?


AT-SPI, the Assistive Technology Service Provider Interface, specifies the information that is provided by accessible applications to assistive technologies (and the questions ATs can ask of apps). Our implementation of AT-SPI uses CORBA for interprocess communication (the AT lives in one process, the app another, so we need some form of interprocess communication).

CORBA is an object based interprocess communication mechanism (the Common Object Request Broker Architecture). The user interface elements in an applications are represented by 'Accessible' objects, these objects have methods, and CORBA allows an AT to make remote, inter-process method calls on these objects (e.g. to ask an accessible for its name, its role, etc.). In order to handle all of the potential issues that can arise with inter-process communication around objects, CORBA is fairly large and complex. It has to handle the case when the remote object goes away, when a method call fails, etc. etc. Memory constrained environments - like the OLCP and the Nokia N800 - don't include CORBA (whereas many desktop systems like Ubuntu and Solaris do). So, if we are to bring assistive technology support to things like the OLCP and Nokia N800, we need to address this situation.

One idea is to see whether we can slim down the CORBA implementation for OLCP/N800, on the assumption that AT-SPI may not need everything that CORBA provides. Another idea is to move do a different inter-process communication mechanism (and the candidate choice here is D-BUS, which has roots in DCOP and the KDE desktop). The big, not fully answered question, is whether a D-BUS implementation of AT-SPI can do everything we need. Recent news from Trolltech labs (the folks behind Qt, the main GUI toolkit for KDE) sounds promising on this front, but I believe a little more investigation and testing is needed before we can be sure this will work for us. On a related note, I have repeatedly heard the suggestion of "moving to IAccessible2" for UNIX. To quote the character Inigo Montoya from the movie The Princess Bride, "I do not think that means what you think it means." IAccessible2 is a port of AT-SPI (or more specifically, the UNO Accessibility API in to Windows. More precisely, it is a port of those portions of the UNO Accessibility API which weren't already in MSAA (Microsoft Active Accessibility, the fairly simplistic and primitive accessibility API Microsoft introduced in 1997). Thus, IAccessible2 is not a complete API, but rather is an extension of MSAA. Also, like MSAA, IAccessible2 uses the Microsoft interprocess communication mechanism 'COM' (Component Object Model). COM doesn't exist on OLPC or N800. While I believe there are ports of COM to UNIX, nobody I know of is suggesting implementing COM on UNIX an alternative to CORBA for accessibility purposes. Because toolkits like GTK+ and Qt have been ported to Windows, and because IAccessible2 is gaining some traction on the Windows platform with JAWS and WindowEyes providing support for it in their screen readers, exposing accessibility information for GTK+ and Qt applications on Windows via IAccessible2 makes a lot of sense. Since IAccessible2 is derived from the UNO Accessibility API, which itself is expressed in AT-SPI on UNIX, having cross platform apps be accessible on both UNIX and Windows via what is essentially the same API (though different inter-process communication implementation) makes a lot of sense.

To the question Halim asked, about what AT supports a D-BUS implementation of AT-SPI, I believe Trolltech labs a fork of Dasher that uses it. As the GNOME Dasher makes fairly simple and limited use of AT-SPI, this is a natural first AT to test out. But as it is nowhere as heavy a user of AT-SPI as something like Orca, this port doesn't definitely answer questions about whether we can do everything we need to in a D-BUS based AT-SPI. I know there are other, KDE AT tools, but I don't think any of them make heavy use of the API either. All of them pre-date Trolltech's work in this area, and I haven't seen any mention of them being updated.

Another important facet to this whole discussion is the question of whether we actually need to fork/port AT to use the D-BUS implementation. The Accerciser project introduced a Python abstraction layer to CORBA AT-SPI. Moving our Python-based AT (like Orca) to this abstraction layer would allow us to substitute something else for CORBA (e.g. D-BUS), without needing to fork/port/modify Orca at all. Orca could use CORBA-based AT-SPI on those platforms where that approach made sense, and something else (e.g. D-BUS) on others, where that was a better choice. CORBA and AT-SPI have a lot going for them. They are tested and proven technologies. It may make sense to stay on CORBA for a while in the desktop world, even as we move to something else in memory constrained environments like OLCP and N800.

I hope this helps clear up a lot of the questions and confusion around these topics


Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]