[Kde-accessibility] Re: Qt Accessibility

[Maks Orlovich]

On Tuesday 15 July 2003 08:25 am, 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.

> 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. Moving the QAccessibleWidget
> helper class into the Qt API will probably be a good idea.

I guess something like QWidgetFactory, (or however that thing in libqui is 
called, which one can subclass to add support for new widgets), would be a 
good model for this.

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

An another option is what I've prototyped Klavi with. I've added a new type of 
plugin, xaccess, and a qtrc key to load a few plugins by name, and just make 
QAccessible broadcast ::updateAccessible to the loaded plugin. The big 
advantage is that this does not tie the API to any particular interface, 
which gives more flexibility to try new things (particularly when not 
everyone is sure that a particular approach is the best one, prototyping can 
be helpful). See http://mail.rochester.edu/~mo002j/klavi/qt_xaccess_concept.
diff (I've mostly copy-pasted from QStyleFactory/QStylePlugin). 

QCom might be a bit of a big hammer, but the Q*Plugin type classes abstract it 
very well, and IMHO making things Qt'y at least at this end is quite 
worthwhile.