[Kde-accessibility] On Qt accessibility and a on-screen
Olaf Jan Schmidt
ojschmidt at kde.org
Tue Jul 8 11:29:54 CEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
Thank you very much for your detailed comments.
> this probably needs a new QAccessible plugin to handle KToolBarButtons,
> which do drop downs quite differently from their Qt counterpart.
Indeed. A lot of KDE widgets will need new QAccessible plug-ins
> One major concern of mine is an apparent (correct me if I am wrong)
> lack of plans for a native API.
The documentation is by no means complete. As there were no plans for at
clients up to now, I planned to mentioned possible ways of adding a
native client-side API in the introduction. Now I believe we should
dedicate a page of its own for it.
Generally, the idea is that the KDE API will be very close to the
functions in AT-SPI. While testing QAccessible and waiting for Trolltech
to extend Qt, we can temporarily map these functions to DCOP.
Later we can write a library for kde-accessibility that bridges them
either to AT-SPI directly (would only need a C++ CORBA dependency) or to
the GNOME equivalent of this library (cspi). This would depend a bit on
which would be more work, which would be the exact dependencies, etc.
> I think past experiences with projects like aRts show that systems that
> have their own way of doing things, which is not consistent with the
> rest of KDE tend to stagnate severely, as few people are willing to deal
> with them.
This is an important point, but if interoperability is important for us,
then using a QString-based bridging library seems to be the best
If we use an incompatible API, there are two possible outcomes:
1. Most likely: People needing accessibility and people working on
accessibility will see that AT-SPI has more functionality and wider
support than our new DCOP version, and decide to use and write AT clients
for AT-SPI only. Application authors will see that any efford to make
their applications accessible by providing QAccessible objects will not
help most accessiblility users, and hence not write such plug-ins. This
would mean that KDE accessibility would stagnate as a whole, and KDE
would still be inaccessible using most AT clients.
2. Enough people will use the DCOP solution to keep it alive. People
relying on assistive technologies will have to decide to either only use
KDE programs, or not use any KDE programs at all. People writing
assistive technologies will have to decide which solution to support,
thereby leading to a stagnation of accessiblity support as a whole.
I think defining a Qt-based API that is close to AT-SPI would be a
reasonable way for KDE to go.
> Permanent requirements on ATK or AT-SPI also seem undesirable, although
> quite less severe than the API issue.
Yes. We also didn't like this, but after long discussions of the topic, we
came to the conclusion that incompatibility, or two RPCs and an external
bridge, would be more pain.
Maybe I should mention that I see this very much from a users perspective:
My mother will very likely need assisitive technologies before KDE will
be ready to support it. That's why I am convinced we need an
interoperable solution as quickly as possible - as long as it makes sense
> I must also add that DCOP offers a very easy to use programming
> environment, requiring close to 0 code to support.
Yes, I know. The work would be to in supporting DCOP, but in re-writing
every AT client that exists for AT-SPI. And if we plan to bridge from
DCOP to AT-SPI, we will have more work than if we bridge directly.
> Are there any more other than GOK and Gnopernicus? BTW, I have not been
> able to get anything but the vanilla input mode in GOK to work; which
> is not very impressive since just sending keystrokes doesn't require an
> accessibility infrastructure.
Did you run it under GNOME?
I these comments on a client side API make sense to you.
Olaf Jan Schmidt, KDE Accessibility Project
KDEAP co-maintainer, maintainer of http://accessibility.kde.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the kde-accessibility