[Kde-accessibility] Re: Qt Accessibility

Volker Hilsheimer vohi at trolltech.com
Wed Jul 16 16:16:13 CEST 2003


> > In Qt, the root accessible object would be an QAccessibleInterface for
> > QApplication. The children would be what
QApplication::topLevelWidgets()
> > returns (probably with some exceptions, e.g. no tooltips, no popup
menus
> > etc).
>
> Thanks for sharing this, I didn't know this and it's quite helpful.
> Perhaps something that could be in the docs (if I didn't just miss it,
> which is quite likely)

Hm, when I say "would be" I mean "will be". Right now there is no
QAccessibleInterface for QApplication, but that's probably what we will do
for "the Qt to come".

> > > 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.
> >
> > A plugin approach implies that multiple plugins can be installed.
After
> > reading Maks' mails I'm not sure if this is what is meant with "just
make
> > QAccessible broadcast ::updateAccessible to the loaded plugin". A
plugin
>
> Yes, just a loop, i.e. in particular:
> + for (QValueList<QXAccessProvider*>::iterator iter =
> qt_x11_accessible_providers.begin();
> + iter != qt_x11_accessible_providers.end(); ++iter)
> + {
> + (*iter)->updateAccessibility(obj, who, reason);
> + }

Hm. This might come in handy to support brokers that use Corba, or QCop,
or D-Bus etc. I'll think about this.

> > approach also requires a predefined interface between Qt and the
plugin,
> > and of course a plugin has zero chance to control if Qt uses it or
not.
>
> It can if the plugins to load are configurable through qtrc.

All plugins should be treated equally, e.g. all plugin receive the root
objects, and all plugins receive the call to updateAccessibilty(). Then
each plugin (ie. each broker system) can do what it wants.

> > A single library with a given name and API makes most sense IMHO. If
you
> > don't like the implementation you can still use a different library
(and
> > this *could* be configurable through e.g. qtrc).
>
> You can only use a single library, however. So if the API is not capable
> enough to do what you want, the app can't work. I am not certain ATM
> whether AT-SPI is capable enough for Klavi, for instance. Klavi already
> does some things GOK can't, and I'd hate to kill them because the API
> wouldn't be capable enough.

Agreed. Making Qt as flexible as possible is certainly on of the top
design goals. The problem of being not able to support statically built
applications is the same for plugins and for a single shared library, and
probably rather serious. Distributing a Qt application statically linked
is a common choice on X11.

> > That should be ok - queryAccessibleInterface caches
QAccessibleInterfaces
> > already.
>
> I was actually going to ask about this.. The cache currently does not
dump
> the entry when the object is deleted; which means the caller has to call
> ->release() once it's done with the interface, and the cache only helps
> for redundant queryAccessibleInterface's (while one is active). Is this
by
> design, or a bug? (An alternative is to only call ->release() if the
> interface return has !isValid(), and re-acquire, but that's mighty ugly
> and kind of assumes internals of QAccessibleWidget, i.e. the keeping of
a
> guarded pointer to a widget)

That's a bug, which simply doesn't make trouble because MSAA works
completely request based (ie. there is no root object), so MSAA releases
the interface acquired almost immediately. We'll clean that up of course
when we start working on the code.

> > Note that you cannot call QAccessibleInterface at all from the non-GUI
> > thread, as you would then be able to call property setters in GUI
objects
> > (ie. right now via setText, or doDefaultAction). So if the bridge
starts a
> > thread for IPC it will then have to translate the incoming calls to
> > QApplication::postEvent, and wait for the GUI thread to process the
event
> > (through a wait condition). That would be pretty straight forward, and
> > requiring a threaded Qt support should not be an issue.
>
> DCOP also doesn't need this, as it just uses the event loop; and I
imagine
> other IPC solutions could be made to intergrate with QSocketNotifier &
co.

That would be the best solution of course, but if a Corba ORB has to
perform work hooking into the running and unmodified event loop will be
tricky. I guess connecting to QEventLoop::awake() might work though.

Volker



More information about the kde-accessibility mailing list