1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
README
at-spi version 1.19.5
This version of at-spi requires atk 1.17.0 or later.
*** Welcome to the Gnome Accessibility Project! ***
If you have not already done so, please visit
http://developer.gnome.org/projects/gap
for background information on accessibility, the Gnome
Accessibility Project, mailing list info, and project status.
Contents of this package ==================================
The directories within this package are arranged as follows:
idl : this directory contains the interface definitions
(in Interface Definition Language) for the
accessibility support interfaces exposed by
the AT central registry, accessible applications,
and UI components.
Though IDL is often associated with CORBA, and this
implementation of the at-spi is CORBA-based, these
interfaces are not CORBA-specific, rather they define
the abstract "contract" between accessible application
and client assistive technology.
Assistive Technologies will not normally be concerned
with the underlying implementation details of the IDL.
libspi : this directory contains implementation-specific
code which connects the in-process ATK interfaces
(implemented by GTK+ and, potentially, by other
native-code UI toolkits) to the interprocess SPI.
It also contains implementation code used by the
central accessibility registry. These sources are
used to build libspi.so, a shared object library which
is used by accessibility clients and servers alike.
This interfaces exposed in this library are ordinarily
not directly used by AT, but are used by the C bindings,
thus AT must dynamically link to this library.
registryd : this directory contains code specific to the
central accessibility registry, and the registry
executable is built in this directory.
atk-bridge : this directory contains code that bridges
the at-spi to the GTK+ toolkit, and which is
loaded at runtime by GTK+-based Gnome applications.
The 'bridge' automatically registers GTK+-2.0
applications with the accessibility registry,
and relays UI events from application to registry.
It is also responsible for servicing requests from
the registry to register handlers for specific event
types.
cspi : this directory contains the C bindings for use by
ATs, and the code which adapts the implementation-specific
code to the C bindings API. The header file
"spi.h" contains the API declarations used by AT clients.
pyatspi: this directory is an unified python binding used by ATs.
tests : this directory should be called 'examples', since
it contains not only test programs, but examples
of how to use the AT-SPI. The sample program
"simple-at.c" is currently the primary example of
how the C bindings API should be used.
docs : this directory contains documentation for the AT-SPI.
Documentation is currently limited to API documentation
for the C bindings API, and is built from sources
via the 'gtk-doc' system.
Building the documentation ============================
Pre-built versions of the HTML documentation are available at
http://developer.gnome.org/projects/gap/tech-docs/at-spi-docs/book1.html.
However the documentation in the docs directory is the most up-to-date.
Building the docs requires docbook and jade, see the 'gtk-doc'
package (from Gnome CVS) for more information.
Use of the AT-SPI ======================================
Accessible applications will register with this registry service
(via bonobo-activation) and adaptive/assistive technologies will
register with the service as well, to indicate their interest in
receiving UI events. ATs can also use the registry's services
programmatically to query accessible applications.
Running the test programs: ============================
At the moment the only clients and are two test at clients
('at' and 'simple-at'). There is also a test app ('app) in
the 'tests' subdirectory.
If you have a working ORBit2/bonobo-activation installation you can
run the tests after adding the registryd directory to the
bonobo-activation directory list with bonobo-activation-sysconf,
or by installing Accessibility_Registry.server in your
bonobo-activation 'servers' directory.
You can then run './at' and './app' from the 'test' directory, to see
'app' register as an application, and 'at' as a listening client.
Bonobo should take care of the job of bootstrapping the registry daemon
('registryd') for you. These test programs use the bonobo/CORBA
C bindings directly.
The third test program, "simple-at", is a better illustration of how
most actual AT should use the at-spi, via the C bindings library
(documented online at
http://developer.gnome.org/projects/gap/tech-docs/at-spi-docs/book1.html).
Though 'simple-at' will work with the test application 'app',
a better demonstration of the AT-SPI can be made after installing
libspi and libcspi (via 'make install'). If you set the GTK_MODULES
environment variable to "gail:atk-bridge", any GTK+2.0
application run subsequently will register with the at-spi registry,
and 'simple-at' will register for and receive focus and
buttonpress events from those applications.
At the moment application and at deregistration are not 100% reliable,
so if you get you are advised to kill the registry daemon if you exit either 'at' or 'app'
instances, via the 'bonobo-slay' command. You may run as many instances
of each application or sample AT client as you like, concurrently -
you may find it useful to do so in separate terminal windows.
'at' connects to the registry as an event listener, then queries the
service for the number of virtual desktops (currently always 0 or 1),
and queries each desktop for the accessible applications it is running.
It then prints out the name of each such application (as reported by the
application's accessibility interfaces), and then waits to receive events.
'app' connects to the registry as an application, then dispatches an
event which the registry should relay to all registered listeners.
Thus instances of 'app' run after 'at' should cause the 'at' instances
to receive events.
-Bill
|