[Kde-accessibility] Re: Qt Accessibility
Gunnar Schmi Dt
gunnar at schmi-dt.de
Tue Jul 15 21:02:50 CEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Tuesday 15 July 2003 14:25, Volker Hilsheimer wrote:
> > Hi Volker!
> > It would be nice if you could have a look at some ideas regarding
> > QAccessible* at http://accessibility.kde.org/developer/kdea11y.php
> > Also, I have a question regarding the accessibility plug-ins: How do you
> > provide plug-ins with QAccessibleInterface objects? There does not seem
> > to be a documented API.
> > Olaf.
> Hello Olaf,
> There is indeed no documented API for accessibility plugins right now. The
> current infrastructure still uses QCom directly (the later deprecated API
> introduced in the Qt 3.0 betas), which is also used in the internals of
> e.g. custom widgets for Qt Designer, image format plugins or SQL drivers.
> For those we have dedicated plugin classes that hide the nasty details,
> e.g. QWidgetPlugin, but the concept is the same.
This is a point that needs to be changed IMHO. It would be good if you could
create an official API for providing such plug ins.
> queryAccessibleInterface is then called by Qt to respond to a request from
> the AT client application (ie. WM_GETOBJECT on Windows).
> Adding such functionality to QObject does not make much sense IMHO. For
> most cases this function would return the null pointer, as most QObjects
> are not supposed to be accessible in the first place (QTimer etc.). Having
> this in QWidget would be a better idea, but would require a public API in
> QWidget, which sort-of indicates that this function can be called
> reasonably by anybody (which it can not, as providing such an object makes
> only sense when answering the request).
> What would probably make most sense is a way to install non-plugin-based
> factories. This factory can then reside in the application binary rather
> than in a separate plugin, which makes it easier to implement
> QAccessibleInterface for custom widget.
That sounds reasonable. I only suspect that it might be harder to tell people
`write a factory' than to say `implement a method'.
> Moving the QAccessibleWidget
> helper class into the Qt API will probably be a good idea.
Definitely. Maybe it should also be possible to get the accessibility
implementation for the parent class type (for internal use) if you extend a
given widget and only need to add one little detail to the accessibility
> What would be important for us to know is how Qt can communicate with the
> AT-SPI bridge. How does the Qt application get notified that it is
> supposed to provide a QAccessibleInterface, how does Qt pass that
> QAccessibleInterface to the bridge library, and how does Qt pass
> notifications on to the bridge.
In AT-SPI the application needs to register with the accessibility broker
(also called registry) once it has started. The registry then calls a method
of the application to enquire the root accessible object. From this object
all other accessible objects need to be reachable by
parent-child-relationships. (I would guess that the windows of the
application are the children of the root accessible object). The notification
is done by calling a method on the registry for every single event that
occurs. I would say that we could do similar things for the interface between
Qt and the accessibility bridge.
> As discussed on the web, a solution that introduces no dependencies to Qt
> would obviously be the best. Hence I guess a shared library with a defined
> name and C-API would be the best (since the bridge would only work on the
> pure-virtual QAccessibleInterface it wouldn't even have to link against
> Qt, and only bootstrap some classes used by the API, e.g. QString, QRect
> and QMemArray; linking the bridge against Qt would however not be a
> Qt could then try to dlopen that library when the first request comes in
> through the event loop (at this point, QAccessible::isActive() returns
> TRUE if the library could be loaded), and resolve two basic functions from
> that shared library:
That sounds similar to the plug-in approach discused on the web pages, only
that the loading mechanism gets simplified and is no longer flexible.
However, it does not need to be flexible if the bridge is the only `plug in'
for the given interface.
> - ProvideAccessibleObject( QAccessibleInterface *iface, int requestID )
> This function would be called to handle the request from the AT client.
> The client request would most likely be sent to a Qt widget (since
> initially only widgets are visible for the client) through a defined
> QEvent (or any other message system Qt can handle through the event loop),
> specifying a requestID to ensure synchronization with the response. Qt
> calls QAccessible::queryAccessibleInterface(...) for the object that
> received the message, gets a QAccessibleInterface from either a plugin or
> a factory, and passes that QAccessibleInterface on to the bridge library,
> which then bridges the API to AT-SPI.
I don't get what you mean with this method. As far as I understood it is
sufficient if the bridge provides a function
initialize (QAccessibleInterface *root)
The only parameter of this function is the root accessible object of the
application. All information of the other objects can then be reached by
> - NotifyAccessibilityUpdate(QAccessible::Event, WinID window, int childID)
> This function would be used in the Unix implementation of
I would use the signature
NotifyAccessibilityUpdate(QAccessible::Event, QAccessibleInterface *iface, int
That way the bridge does only need to cope with QAccessibleInterface objects.
Of course that implies that there is always only one QAccessibleInterface
object for each given QObject.
> Does this make sense to you? Are more callbacks required to handle e.g.
If the bridge needs to do things independently of the application, e.g. for
IPC, I would suggest that it internally creates a new thread when the
initialize (...) function is called. Of course that would imply that Qt gets
compiled thread-safe. If that is too much a requirement then I have to look
into which IPC protocol we will be using in order to tell which callbacks are
> Also note that Qt right now does not fire all possible events (ie.
> ObjectShow, ObjectHide is never sent by Qt for widgets, as Windows does
> that already). Is this something we should do for other platforms? Are the
> Events, States and Roles etc. we have in QAccessible sufficient?
Well, I did not yet find the time to do a one-by-one comparison of the events,
states and roles, so I hope it is sufficient to give some pointers into the
The states are documented in the documentation for the AtkStateType
(http://developer.gnome.org/doc/API/2.0/atk/atk-AtkState.html), the roles in
the documentation for the class AtkObject
(http://developer.gnome.org/doc/API/2.0/atk/AtkObject.html). Possibly also of
interest for you are the layers (also in the documentation for the class
AtkObject) and the relationships. The latter are documented in
Unfortunately there is no place in the ATK or AT-SPI documentation where all
events are listed. However, by looking into every interface of ATK I found
the following events:
Visible data change
Text attributes changed
Text caret moved
Text selection changed
There may be more if I overlooked them.
> We will discuss the Qt Accessibility Architecture in Trolltech in a couple
> of days (when 3.2 is out), I'll keep you in the loop.
Good to hear.
Gunnar Schmi Dt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-accessibility