From The Linux Foundation

AT-SPI on D-Bus

contents last updated 30 October 2009

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.gnome.org in the at-spi2-core, at-spi2-atk, and pyatspi2 modules.

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. However, some widgets, such as Gtk treeviews and OpenOffice spreadsheets, may have numerous children that they create on an as-needed basis, so it would not be useful to enumerate them. These objects indicate this by setting the MANAGES_DESCENDANTS state. In the long term, we may want to change the way these objects are handled so that applications do not need to expose what could be an infinite space. However, it is important that existing applications continue to work without modifications, particularly applications not tied to GNOME, since they would otherwise need to act differently depending on which version of atk is present. The solution that we are using is for atk-bridge to 'lease' children of ManagesDescendants objects; if these objects are not visible and are not accessed by a client for 30 seconds, then they may be garbage-collected. 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

Gnome has decided that the 3.0 release will be free of ORBit and Bonobo meaning a D-Bus AT-SPI solution is required.

AT-SPI D-Bus is a translation of the AT-SPI interface originally specified in CORBA idl. The project implements a number of ORBit based libraries and programs in D-Bus.

These modules are:

atk-bridge
cspi
pyatspi
registryd
loginhelper

The status of each of these as well as work required on the D-Bus interface itself and infrastructure needed outside of the AT-SPI D-Bus project are detailed below.

Accessibility/ATK/AT-SPI/AT-SPI on D-Bus/DublinHackfest

AT-SPI D-Bus Libraries

registryd

The registry daemon has two distinct tasks.

Keeping track of all the accessible applications on the desktop.
Dealing with and forwarding X events over AT-SPI D-Bus.

The registry of accessible applications is relatively simple and has been fairly well tested.

Possibly XEVIE code should be removed as this will not be available in future X.org releases.

pyatspi

A client side library, in python, for access to AT-SPI accessibility information.

All D-Bus method calls in python are synchronous and are not re-entrant. This can cause deadlock. Need to make a re-entrant D-Bus method call available in python and change all synchronous calls over to this. This should be working in latest git.

cspi

A client side library in 'C' for access to AT-SPI accessibility information.

It is unknown how much work is required to complete this library. It has been working and tested previously, but has not been updated with protocol changes and has never been heavily tested.

loginhelper

An extension for enabling accessible login.

Unsure

AT-SPI D-Bus Specification

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 has been written in Telepathy D-Bus XML.

Investigate the correctness of the 'Collection' and 'StreamableContent' interfaces. This goes along with implementing these interfaces in the atk-bridge.
Write XSLT to convert Telepathy XML into readable documentation.
Possibly re-write the specification in in a yet-to-be-decided D-Bus IDL.
Create new interfaces for management of large or infinite spaces.

Additional interfaces may be required for the management of accessible object life-cycle within infinite or very large containers. In the Bonobo / ORBit specification accessible objects were remotely reference counted and this was used as the method to manage their life-cycle within very large containers. Remote reference counting has been removed, meaning that new interfaces may be required.

The importance of this is possibly over-stated. Firefox exposes the entire DOM and does not have this problem. Open office exposes only the objects visible on-screen and therefore sidesteps this issue.

Related Infrastructure

Multi-user accessibility

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.

AT-SPI D-Bus would prefer an 'X session' D-Bus bus, as this would allow applications to run as root within the same X session and remain accessible. This will require liaison with the D-Bus community, to make our case for an X session bus. If this isn't possible D-Bus AT-SPI should create its own, exclusive, D-Bus bus that is tied to the X session.

This would still require some core D-Bus work as the D-Bus bus program currently won't allow connections from a different users. This would have to be turned into an optional feature.

Remote Accessibility

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.

Gnome inclusion

High Priority

Multi-user accessibility - Required for accessible system administration.

Pyatspi - Not a-lot of work. Need to test with orca.
atk-bridge. - Need a solution for the collection interface (partly done but not committed) and leasing of Transient objects (code in mgorse branch but needs testing).
registryd - Need to refactor the DeviceEventController, and ensure that without XEVIE we can meet all requirements for device events.

Low Priority

Readable documentation / specification for the D-Bus interface.
Accessible remote applications.
Infinite space containers.
Cspi - There has been alot of discussion about whether to complete cspi, or a subset of cspi. There are several programs that currently use the cspi binding (LDTP, gok, and dasher). However, ldtp has been (mostly?) ported to pyatspi, gok is being rewritten in Python, and dasher makes very limited use of cspi and can be modified to use dbus directly.

Packaging and Gnome integration

Some packaging work will be required. At least provide debian packages as an example of preferred package structure and dependancies.

The git repository has a branch 'debian' that has a debian/ folder for building some initial debian pakages.

Gnome integration will be required, a jhbuild module and tests building AT-SPI D-Bus using jhbuild.

At-spi2 is slated to be used by default starting with GNOME 2.29.2. However, users may want to have the option of switching to the CORBA-based at-spi (if there are things not yet working in the dbus-based at-spi, for instance). It is not recommended to try to use both versions of at-spi simultaneously. However, both versions should be able to coexist on a filesystem if they are built with different prefixes. The CORBA-based at-spi will be enabled by a new gconf setting. This setting will be used when deciding whether to star the CORBA-based at-spi-registryd, and the CORBA pyatspi will include a .pth file which will point Python to it if this gconf setting is set.

Instructions for Building

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

System install issues

The ATK Bridge will be loaded into every GTK application, possibly causing instability at this early stage.
The python module conflicts with the CORBA based pyatspi, so they may not be installed together. In the future, the CORBA-based pyatspi will likely include a tweak to allow it to coexist with the dbus-based pyatspi provided they are built with different prefixes, although it will not be possible to use both versions simultaneously.

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-spi2-registryd

The ATK Bridge library will be:

/usr/local/lib/gtk-2.0/modules/libatk-bridge.so

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)

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)
> cd src/
> python accerciser

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.

[Article] [Discussion] [View source] [History]