contents last updated 17 November 2008

• 1 AT-SPI on D-Bus
  • 1.1 Introduction (skip to main contents)
    • 1.1.1 Document Revisions
    • 1.1.2 Page Contributions: Instructions & Requirements
  • 1.2 Background
• 2 AT-SPI D-Bus design
• 3 AT-SPI D-Bus Project Status
  • 3.1 Completed work
  • 3.2 TODO
  • 3.3 Instructions for testing
    • 3.3.1 Multiple applications
    • 3.3.2 Single application
    • 3.3.3 Accerciser issues
  • 3.4 Future Plans & Releases
• 4 Questions & Queries from Developers

Introduction (skip to main contents) AT-SPI technologies are currently migrating to D-Bus for their transport technology. As such, this document serves as a tutorial, design document and project update page for the AT-SPI D-Bus project. Document Revisions

• Current Version: ''http:%%//%%a11y.org/d-bus''
• Previous Version: ''http:%%//%%a11y.org/a11yspecs/atspi/AT-SPI_on_D-Bus_20080730.html''

Page Contributions: Instructions & Requirements

• Small factual errors or ambiguities should simply be updated with an improved wording.
• For open issues, marked with the string ToDo:, please add your name to comments. Such discussions should be replaced with an updated summary of the point once a conclusion has been reached to help readability.
• Please add a date wherever the information is subject to possible change in the future.
• Please update outdated content.

Background AT-SPI was originally designed for, and is currently implemented by the GNOME project using CORBA, an object-based IPC/RPC technology. CORBA is very portable but somewhat heavier weight than D-Bus.The AT-SPI specification itself is tied to CORBA as it is defined in CORBA IDL. ORBit as an inter-process communication technology has many problems going forward, is deprecated in the Gnome project. CORBA does not exist in the KDE project and is generally resisted in embedded developments.

In an effort to move AT-SPI forward, a D-Bus project was started in November 2006. This took the form of a performance and design review available on the GNOME wiki. Work began on the implementation in May 2007.

Work is on-going and the project code is currently hosted at git://git.codethink.co.uk/git/atspi-dbus.

AT-SPI D-Bus design Remote reference counting is not being implemented for performance and complexity reasons There is a new caching mechanism where data accessed most often is transferred with accessible objects and will be cached by the AT-SPI bindings to avoid the need to make unnecessary round-trip calls. Wherever possible, including application events, synchronous method calls have been replaced by asynchronous D-Bus signals.

In other aspects the protocol is essentially the same as the current, IDL specified, at-spi interface. The two are intended to be completely compatible. This is so that API compatible bindings may be generated and ATs may be re-used with minor modification. AT-SPI D-Bus Project Status The code is currently under heavy development and is not expected to be able to replace the CORBA based AT-SPI until 2009. Completed work

• The AT-SPI IDL specifications have been translated into the D-Bus introspection XML with annotations based on the telepathy XML.

• The ATK Bridge is an adapter that exposes toolkits made available by the ATK interface over D-Bus AT-SPI. All interfaces have been written except for the StreamableContent interface. Some of the interfaces have been unit tested.

• Pyatspi is a client side interface for accessing accessibility information. A library implementing the pyatspi interface has been written for AT-SPI D-Bus. It is complete and has been somewhat tested using Accerciser and Orca, but needs deeper testing to ensure the interfaces are compatible.

• Cspi is the 'C' client side library. It has been written but is largely untested. It is currently not working due to changes in the D-Bus AT-SPI protocol.

• The registry daemon has two roles. It registers applications that wish to be made accessible. It forwards device events to registered event listeners. The registration protocol has been defined and implemented. The device forwarding code has been translated from the CORBA implementation but is largely untested.

ToDo

• Previously the AT-SPI protocol was defined in CORBA IDL. The AT-SPI specification is now in D-Bus introspection XML with telepathy annotations. This is very difficult to read, and not trivial to modify. Tools have been written to convert the specification into some 'C' enumerations and structures but little else. It would be very useful to translate the specification into readable documentation. A larger project would be to create a D-Bus idl describing and documenting the messages.

• The Device Event code in the registry daemon needs improving. Currently there are a number of warnings related to invalid signal names. The code is somewhat messy. Some tests need adding to the code-base to cover device-events.

• Cspi bindings are currently not working. They need to be modified to fit new registration and event protocols. They need to have unit tests added. The eventual goal is to investigate their use with GOK.

• One of the major goals of this project was cross desktop accessibility. Towards this goal a QT bridge needs to be implemented.

• AT-SPI D-Bus created its own server-side D-Bus framework called 'droute'. A client side framework called 'dbind' was appropriated from Michael Meeks. It would be useful to separate, document and improve these frameworks as they may be useful outside of AT-SPI. There is some functionality missing, such as signal emission and registration that might clean up the code within AT-SPI.

Instructions For Testing Assume that when configuring the project:

GTK_MODULE_DIR = /usr/local/lib/gtk-2.0/
pythondir = /usr/local/lib/python2.5/
libexecdir = /usr/local/libexec/

Then the registry daemon executable will be installed as:

/usr/local/libexec/at-spi-registryd

The ATK Bridge library will be:

/usr/local/libexec/gtk-2.0/modules/libspiatk.so

To use AT-SPI D-Bus a normal 'make install' can be used with the following caveats:

• There is no provision to add the registry daemon to startup scripts; it must be started manually.
• The ATK Bridge will be loaded into every GTK application, possibly causing instability a this early stage.
• The python module conflicts with the CORBA based pyatspi, so they may not be installed together.

Multiple Applications To make multiple applications accessible or test the DeviceEvent functionality and registry daemon:

> /usr/local/libexec/at-spi-registryd  &                               (Load registry daemon)
> gcalctool --gtk-module=/usr/local/lib/gtk-2.0/modules/libspiatk.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)

Single application AT-SPI D-Bus can be used without the registry daemon for testing the core AT-SPI interfaces. AT's will not be made aware of only a single application and DeviceEvent functionality is not enabled.

> gcalctool --gtk-module=/usr/local/lib/gtk-2.0/modules/libspiatk.so & (Make an application accessible over D-Bus)
Application registered on D-Bus path :100
> export PYTHONPATH=/usr/local/lib/python2.5/                          (Ensure new pyatspi is found)
> export ATSPI_TEST_APP_NAME=:100                                      (Tell pyatspi the D-Bus path)
> orca                                                                 (Load an AT using pyatspi library)

Accerciser issues Accerciser seems like the ideal AT to use to test the AT-SPI D-Bus software. Unfortunately it is difficult to use with PYTHONPATH. Accerciser modifies the python search path on startup, so only libraries in default python install directories are used. Accerciser can be loaded in-place from its source directory without this problem.

Assume we are in the accerciser source directory, to load with a single app:

> gcalctool --gtk-module=/usr/local/lib/gtk-2.0/modules/libspiatk.so & (Make an application accessible over D-Bus)
Application registered on D-Bus path :100
> export PYTHONPATH=/usr/local/lib/python2.5/                          (Ensure new pyatspi is found)
> export ATSPI_TEST_APP_NAME=:100                                      (Tell pyatspi the D-Bus path)
> cd src/
> python accerciser

Future Plans & Releases An initial release of D-Bus AT-SPI will take place once we are convinced that Pyatspi and the ATK Bridge are functionally complete. They should pass the Orca test cases. The initial release will probably not include Cspi or QT accessibility. Questions & Queries from Developers

• Andrés G. Aragoneses: Feedback from GNOME Hackfest 2008 (2008-10-17):
• One thing I learned in the summit as well is that there are still a bunch of important core parts of gnome that still use Bonobo (gconf for instance) even when there exist a dbus counterpart (gconf-dbus), which IIRC worked pretty well. Any insights about the reasons?
• Mark Doffman: Reply (2008-11-10)
• In the specific case of GConf there have been ongoing discussions about making wider ranging changes to the GConf library, and that this should go along with the D-Bus move. (See the DConf page). I haven't heard of any technical reasons why GConf has not moved to D-Bus. An implementation already exists and can be found on the Imendio page.
• Andrés G. Aragoneses: Feedback from GNOME Hackfest 2008 (2008-10-17):
• the vala&GObject-introspection topics where pretty interesting. I wonder if we should have used vala for at-spi-dbus (and prevent more memory leaks this way).
• Mark Doffman: Reply (2008-11-10)
• AT-SPI D-Bus could have used Vala for the ATK Bridge. This was initially adapted from the ORBit based 'C' version so a different programming language was not considered. The Vala D-Bus bindings are not completely stable, so extra work may have been required on the underlying tools.

• return to the ATK/AT-SPI SIG main page
• AT-SPI Documents, References & Specifications