[Kde-accessibility] Re: Qt Accessibility

[Maksim Orlovich]

> 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)

> > 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);
+	}


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

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

> 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)

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