• content maintainers:
• Mark Doffman, CodeThink
• Mike Gorse, Novell

• High Priority List for AT-SPI D-Bus Port
  • Regression Testing
  • Performance
  • GConf and GSettings issues
  • Multi-User Sessions
  • Caching Application Events
  • CORBA Support
  • Qt Issues
  • Cspi Issues
• Priority List for AT-SPI D-Bus Port
  • Key Events
  • Re-entrancy
  • User Testing
  • Integration
  • Installation and Packaging
  • Accessibility Bus
  • KDE
  • JHBuild
  • Firefox
  • Specification
  • ATK bridge location

To be considered ready for testing in the open AT-SPI D-Bus must first pass the Orca test suite. Orca has the largest test suite of all accessibility applications and provides the best test for AT-SPI D-Bus. Previously AT-SPI D-Bus has performed very badly in these tests. Many of these failures may be performance related as the failures were different on lower specified PCs. Other failures are likely related to the caching used to improve performance. The caching means that if signals are missing to update accessibility values AT-SPI D-Bus will provide different data to the AT-SPI CORBA implementation.

Another test suite to consider would be the Mago test suite. This is a desktop testing suite for Ubuntu. It makes use of accessibility technologies and so would be a decent additional test for AT-SPI D-Bus.

Moving AT-SPI from CORBA to D-Bus has lead to a decrease in performance. D-Bus IPC is not as fast as CORBA for the AT-SPI API. This has been mostly mitigated by the use of client-side caching of accessibility information.

Accessibility uses GConf keys to decide when to switch accessibility on. In the last sprint GConf keys were added to switch between AT-SPI D-Bus and AT-SPI CORBA. The GConf code may need to be moved to GSettings API for Gnome 3.0. The keys to switch on AT-SPI CORBA will have to be removed in the final release of Gnome 3.0.

It is a neccessity for multiple users in the X session to participate in deskop accessibility, so that GUI applications running as root are accessible.

The most important part of the multi-user bus work is to complete the Accessibility bus. It should be possible to set the Accessibility bus so that it at least allows root GUI programs to participate in desktop accessibility. Total multi user accessibility, and remote X access is not possible using D-Bus so would require work with D-Bus upstream.

note: there is not yet content for this section.

note: there is not yet content for this section.

The QtBridge used for making Qt apps accessible over AT-SPI D-Bus has not been updated since the 0.1.6 release and is currently non-functional. It needs to be updated for the latest changes in the protocol and its use encouraged within KDE.

CSpi is the client side bindings for “C” applications. A complete version of CSpi for AT-SPI D-Bus has not been written.

One area where AT-SPI D-Bus is still performing badly is with key events. When many 'Tab' key events are sent from an application in succession it can lead to extreme performance degredation. This is probably related to the syncronous nature of key-events, the re-entrancy involved when they are sent, and the work required to deal with the subsequent change of focus.

Method calls in pyatspi are re-entrant. This means that they try to “fake” a syncronous call by re-entering the GMainLoop while making the method call. This has caused issues in the past where there were far too many levels of re-entrancy leading to performance degredation on lower performing machines and failures of the Orca test cases.

Re-entrancy has also lead to failures when using AT-SPI D-Bus with accerciser.

On top of the test suites AT-SPI D-Bus needs more user testing before release.

note: there is not yet content for this section.

In the last AT-SPI D-Bus sprint, there were a number of options added for installing AT-SPI D-Bus at the same time as AT-SPI corba. These compile time options changed how the different parts of AT-SPI D-Bus were installed so that they could safely be installed on-top of a standard distribution that included AT-SPI CORBA. These options have not been documented meaning that it is not obvious how to install the AT-SPI D-Bus releases. These installation options need to be documented.

It would be a good idea to create packages for Ubuntu that use that use the relocation options and can be installed on-top of the AT-SPI CORBA packages for testing purposes. Perhaps these could be placed in a PPA.

During the last sprint, a D-Bus bus was created specifically for accessibility. There is a script in Python that launches this bus. This was integrated with GNOME so that be bus would be launched on GNOME startup. This still needs some work. Currently the accessibility D-Bus bus does not participate in Gnome session management, which it should do. The registry daemon is launched automatically and does not necessarily need to participate with GNOME session management. Currently it does. The session management code will need moving to the D-Bus bus, but this will require that the Python wrapper is re-written in “C”. This wrapper may be similar to the dbus-launch tool and could possibly be added to that.

Currently the releases are GNOME specific. Ideally it would be possible to use these releases with KDE.

AT-SPI D-Bus has been removed from the JHBuild system. It will need to be added back in for integration in to GNOME.

Firefox 3.6 and later crash when using AT-SPI D-Bus. It is an extremely high priority to fix this issue.

The specifications for AT-SPI D-Bus have been specified in D-Bus XML with Qt extensions. This is because the Qt client bindings are the only ones that use it for automated code generation. Ideally the specifications would be written in such a way that other client or server side bindings could be generated using them.

Right now, the atk-bridge module is placed in the GTK+ modules directory. This was because at that moment, the main user of the atk-bridge were GTK+ applications, so place the module there made things easier. But atk-brigde is not a real GTK module. It doesn't have any GTK+ dependency. ATK is an abstract and toolkit independent API. Other toolkits has started to use it. As example Cally. In those cases, applications can't load the atk-bridge using the same GTK_MODULES approach, so (at this moment) it requires to load atk-bridge by hand. One of the main problems is locate where the module is. GTK+ knows were his modules would be placed, but this is not the case for other apps. atk-bridge should be located in a shared and common place, to be used for any toolkit (of course, no problem to keep atk-bridge on the gtk modules directory, to make easier their implementation). This problem was first mentioned the last August [1]. At this moment GNOME Shell has solved it supposing a gconf variable with the direction of the atk-bridge. GNOME-Shell bug [2]. at-spi2 bug [3]

• [1] http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00019.html
• [2] https://bugzilla.gnome.org/show_bug.cgi?id=612599
• [3] https://bugs.freedesktop.org/show_bug.cgi?id=28580