From kde-accessibility Tue Jul 08 07:31:08 2003 From: Olaf Jan Schmidt Date: Tue, 08 Jul 2003 07:31:08 +0000 To: kde-accessibility Subject: Re: [Kde-accessibility] On Qt accessibility and a on-screen X-MARC-Message: https://marc.info/?l=kde-accessibility&m=105764946826777 -----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----- _______________________________________________ kde-accessibility mailing list kde-accessibility@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-accessibility