[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-accessibility
Subject:    Re: [Kde-accessibility] Fwd: KDE Accessibility
From:       "Volker Hilsheimer" <vohi () trolltech ! com>
Date:       2002-11-27 17:28:44
[Download RAW message or body]

> Hello Volker!
>
> Thank you very much for your quick reply.
>
> > One of the issues mentioned that the Qt API for accessibility
support
> > was not versatile enough to be used by KDE, and that the
implementation
> > we have would need to be extended (and implemented on UNIX).
>
> That was our impression, we might be wrong.
>
> Everything we were saying was based on our unclear understanding of
the
> online documentation.

Read: On our understanding of the unclear online documentation ;-)
I guess that there is much we can improve on that...

> > - Qt receives the WM_GETOBJECT message
> > Qt uses the static function QAccessible::queryAccessibleInterface(
> > QObject*, QAccessibleInterface ** ) to get hold of the accessibility
> > implementation for the widget that the WM_GETOBJECT message had been
> > sent to.
>
> How does this static function know about KDE subclasses of Qt Objects?
Is
> there a way to extend this functionality for all KObjects as well?

A plugin implements a factory interface, and this factory interface
returns a stringlist that lists all widget classes the factory can
generate an accessibility-implementation for. I don't know if our plugin
is part of the X11 distribution, so I've attached a zip with the
sources. The factory is implemented in main.cpp.

Now the plugin manager that handles the plugin stuff for Qt loads all
the plugins it finds, asks for their list of "features", creates a map
and uses this map to provide a factory suitable for the classname of the
QWidget you ask for in the static function. If there is no plugin that
provides e.g. KPushButton as a widget it will go up the class hierarchy,
end up with QPushButton, find the Qt default plugin, and use the factory
in that plugin. Assuming that KPushButton has the same behaviour as
QPushButton (at least from an accessibility point of view) it will be
unnecessary to provide special implementations for most subclasses. If
it's necessary you just drop in another plugin.

> > - Additionally to that, Active Accessibility provides a notification
> > mechanism that allows applications to tell accessibility clients
that
> > something important has changed or happend (e.g. a checkbox changed
> > it's state). The static QAccessible::updateAccessibility() is
provided
> > for that, and a large set of "event types" (e.g. ValueChanged) is
> > defined in an enum (the enum values are identical to the respective
> > values in Windows, but can easily be mapped to something else).
>
> That's good. I couldn't figure out how this works from the QAccessible
> class documentation.

I don't know how it works either - I just call NotifyWinEvent ;-)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msaa/ms
aaccrf_76gk.asp

> We would also need information about simple things like a moved
cursor.

Note that QWidget has a function setMicroFocusHint() which we use for
that; on Windows, we position the caret in that function, and
communicate with whatever IME is running, and this is all we need to do
here (Windows generates the accessibility events from that on it's own).
The X11 implementation is communicating with XIM it seems, I don't know
if this is useful enough and if there is anything else we could or
should do, but we can certainly add whatever is necessary to this
implementation (or add another event to the event enum).

> > If it is not sufficient it is trivial to add another interface and
> > implement that as well in the plugins
>
> Great! To be honest, we are not sure ourselves what would be needed.
The
> standard accessibility solution on Linux is coming from Gnome, so we
have
> to learn both Qt and Gnome stuff to figure out the best way how we can
> use existing code best.

Yep; Gnome and Sun have been pushing this rather successfully, and from
what I've seen their interfaces are not much better than the Microsoft
stuff (just more complicated).

> > Any RPC will do for that, and we would definitely be interested in
> > putting some efforts into this (e.g. implement the server side for
the
> > RPC in Qt). Naturally, we would prefer this to be independent of
e.g.
> > CORBA ;-)
>
> That's our interest as well. We don't use CORBA in KDE. :-)
>
> > Well, please fwd. this to the respective lists/people. I would of
> > course like to know more details about what parts seem to be
> > insufficient or not flexible enough, so that we can add some fu in
Qt.
>
> We are still very much in a discussion phase and learning what Sun and
the
> Gnome Accessibility Project exaclty did with their AT-SPI. It would be
of
> great help if you could join the kde-accessibility mailing list
> (http://mail.kde.org/mailman/listinfo/kde-accessibility).

I just subscribed; I'll try to participate, but I cannot promise to be
of great help.


Cheers,
Volker


["accwidgets.zip" (application/x-zip-compressed)]
_______________________________________________
kde-accessibility mailing list
kde-accessibility@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-accessibility

[prev in list] [next in list] [prev in thread] [next in thread]