[Kde-accessibility] On Qt accessibility and a on-screen keyboard. (Klavi[atura])

[Olaf Jan Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Maks!

Thank you very much for your detailed comments.

[Maks Orlovich]
> 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 
solution.

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


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

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

iEYEARECAAYFAj8KgQUACgkQoLYC8AehV8d+4wCcCXVlCh8Lh7CqfSB4JZFkb23p
pSUAoNAoM9idvJlBVl07xe/jS8claSLB
=mQmc
-----END PGP SIGNATURE-----