contents last updated 1 June 2011
The QtBridge used for making Qt apps accessible over AT-SPI D-Bus is being actively worked on but still needs work to be usable.
There is now a C-based AT-SPI binding, called libatspi. It is not compatible with the original CSPI library, so applications that used CSPI would need to be ported to the new library. For the medium term, a compatibility layer could be written to implement the old CSPI API on top of libatspi.
GAIL should be fixed to emit children-changed events when, ie, packing a box (http://bugzilla.gnome.org/show_bug.cgi?id=577392). Since at-spi2 caches children and states, a lack of events when these change will result in the cache not being updated.
On top of the test suites AT-SPI D-Bus needs more user testing before release.
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.
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. TODO: Check this–I think that it is added in again. -MPG
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 . At this moment GNOME Shell has solved it supposing a gconf variable with the direction of the atk-bridge. GNOME-Shell bug . at-spi2 bug 
As well as the libraries using the AT-SPI D-Bus specification some work may still be required on the specification itself.The D-Bus specification was originally written in Telepathy D-Bus XML, but the current code base has the Telepathy extensions removed. There is now a specification in an IDL-like language, but there are currently no tools to generate HTML documentation or C headers from this IDL.
It is a requirement of the D-Bus AT-SPI system that applications running as other users, most importantly the root user, are made accessible on the desktop.D-Bus does not have a multi-user bus, meaning some work will be required to make D-Bus AT-SPI work in the multi user case. D-Bus session busses are not, as sometimes imagined, per-X-session. The session bus is per-X-session, per-user. There has been some discussion about creating a “user bus” which may ultimately replace the current session bus. Such a user bus would likely meet the requirement of enabing accessibility of applications running as root in a user's session.ATSPI D-Bus currently starts its own D-Bus daemon associated with the X session. This behavior could presumably be removed if the “user bus” is added into D-Bus.
This is the requirement to load a program remotely and have it accessible on the local desktop. The multi user work is a prerequisite for this. Possibly the best solution is to have an ICE transport for D-Bus.
There are three separate repositories for AT-SPI D-Bus. The 'Core' repository contains the D-Bus specification as well as the registry daemon and D-Bus helper libraries. The 'Atk' repository contains the AtkBridge library and the currently-broken cspi code, and the 'pyatspi2' repository contains pyatspi (the Python at-spi binding used by applications such as Accerciser and Orca).The 'Core' repository can be downloaded by:
git clone git://git.gnome.org/at-spi2-core
The 'Atk' repository can be downloaded using git from:
git clone git://git.gnome.org/at-spi2-atk
The 'pyatspi2' repository can be downloaded using git from:
git clone git://git.gnome.org/pyatspi2
Libraries in the 'Atk' repository depend on the 'Core' libraries. The 'Core' software must be built and installed before attempting to build the 'Atk' libraries.The libraries may generally be made using:
> ./autogen --prefix=prefix > make install
Assume that when configuring the project:
libdir = /usr/local/lib pythondir = /usr/local/lib/python2.5/ libexecdir = /usr/local/libexec/
Then the registry daemon executable will be installed as:
The ATK Bridge library will be:
The registry daemon should be started automatically by the dbus daemon if atk-bridge or pyatspi request it.To test:
> gcalctool --gtk-module=/usr/local/lib/gtk-2.0/modules/libatk-bridge.so & (Make an application accessible over D-Bus) > export PYTHONPATH=/usr/local/lib/python2.5/ (Ensure new pyatspi is found) > orca (Load an AT using pyatspi library)
dbus-monitor can be helpful for debugging AT-SPI. However, there are a couple of issues to be aware of. AT-SPI method calls are made over direct dbus connections when this is supported on the application side. This significantly improve performance, since messages no longer need to be routed through dbus-daemon, but it makes debugging with dbus-monitor more difficult. Direct dbus connections are enabled by default in at-spi2-atk when dbus-glib 0.90 or greater is available, but they can be disabled by passing –disable-p2p to configure. Libatspi will revert to using the dbus daemon if an application does not support direct connections (ie, if the call to GetApplicationBusAddress returns an error or an empty string). Additionally, when the accessibility bus is in use, it is necessary to point dbus-monitor to use it rather than the session bus. This can be done using a script such as the following:
dbus-monitor --address `xprop -root | grep AT_SPI_BUS | sed -e 's/.*= "//' | sed -e 's/"$//'`
It is possible to get Python backtraces using gdb. This can be useful when investigating crashes that happen within libatspi, for instance. For more information, visit http://wiki.python.org/moin/DebuggingWithGdb. It may help to rebuild python without optimizations (ie, CFLAGS=-g), since the symbols used by the gdb macros may otherwise be optimized out.Due to its more aggressive use of caching, AT-SPI 2 is more sensitive to bugs in which toolkits fail to send events than AT-SPI 1. For AT-SPI 2.0.2 and later, there are methods to control the kinds of data that get cached (atspi_accessible_set_cache_mask for libatspi; setCacheMask for pyatspi). The following values can be specified:
app.setCacheMask(pyatspi.cache.ALL ^ pyatspi.cache.NAME)