[Kde-accessibility] Re: Qt Accessibility

[Gunnar Schmi Dt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Volker,

On Tuesday 15 July 2003 14:25, Volker Hilsheimer wrote:
> [Olaf:]
> > 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 
information?

> 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
> problem).
>
> 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 
parent-child relationships.

> - NotifyAccessibilityUpdate(QAccessible::Event, WinID window, int childID)
> This function would be used in the Unix implementation of
> QAccessible::updateAccessibility()
>
I would use the signature

NotifyAccessibilityUpdate(QAccessible::Event, QAccessibleInterface *iface, int 
childID)

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.
> IPC?

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 
needed.

> 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 
ATK documentation.

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 
http://developer.gnome.org/doc/API/2.0/atk/AtkRelation.html.

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:

Key press
Key release
Children change
Focus
Property change
State change
Visible data change
Selection changed
Column deleted
Column inserted
Column reordered
Model changed
Row deleted
Row inserted
Row reordered
Text attributes changed
Text caret moved
Text changed
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)

iD8DBQE/FEHXsxZ93p+gHn4RAsk/AKC3X7xgfVGQXETb6+bffZ5q137tSwCdFzWk
7arUBBacQYUfECOyTZrgaEs=
=b2uB
-----END PGP SIGNATURE-----