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

[Gunnar Schmi Dt]

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

Hello,

On Tuesday 08 July 2003 06:25, Maks Orlovich wrote:
> On Friday 04 July 2003 05:35 pm, you wrote:
> > Hi Maks!
> >
> > Thank you very much for your work on Klaviatura.
>
> My pleasure.
>
> > I didn't have time to
> > look at your code, but getting QAccessible working is very high on our
> > agenda right now. I am really impressed that menus and toolbars are
> > working.
> >
Well, I took the time to do a quick look at the code. You seem to use explicit
knowledge about the widgets. Is that right? In that case it is more a
demonstration what will be cleanly possible if QAccessible gets extended and
not a demonstration of what QAccessible can do (or not do).

> > Gunnar will give a speech on accessibility at the KDE developers meeting.
> > I think that showing your program at the conference would be a very good
> > way to illustrate what getting QAccessible to work is about.
>
> Well, may be I should make it more complete by then :-).

That would be good. Your current version (the one you sent, not the one in CVS
if there are differences) has only support for menu bars and tool bars. What
I would like to see is the support for the other GUI elements as far as it is
possible without explicit knowledge of the widget types (e.g., in that case a
real demonstration what QAccessibleInterface can do and where it lacks)?

> Anyway, I've put it into kdenonbeta, which makes updating things easier,
> and fixed some bugs.. Still, there are quite a few major gaps and issues..
> The #1 is that it occasionally locks up, but that's not very reproducible,
> making it hard to deal with Other than that, the big thing is the lack of
> support of toolbuttons with drop downs; I think this probably needs a new
> QAccessible plugin to handle KToolBarButtons, which do drop downs quite
> differently from their Qt counterpart. Other things are just more a matter
> of a lack of completeness. (i.e. it doesn't draw separators other than
> empty buttons now, only handles one  keyboard layout, although backend just
> loads it from a file, etc.).
>
During the (few) tests that I did, I had no lock ups. Also I did not find any
missing features in KToolBarButtons. Maybe the popup handling is not that
different between the two? (Or is it because I used KDE 3.1 branch instead of
head?)

One feature that I miss is the possibility to close an open pop up. Is it
possible to add that feature?

> > So please have a look at http://accessibility.kde.org/developer/
> >
> > If you have any ideas or suggestions or improvements concerning these
> > documents, please let us know.
>
> One major concern of mine is an apparent (correct me if I am wrong) lack of
> plans for a native API. 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. Permanent requirements on ATK or AT-SPI also
> seem
> undesirable, although quite less severe than the API issue.
>
Well, we have a native (Qt-)API: QAccessible and its derived classes. From an
application programmers view you do not need any other API. The only case
where a native API could be helpfull is when writing an assistive technology
for KDE. However, as that assistive technology probably wants to help GNOME
applications as well, it needs to speak AT-SPI in either case (unless we
build a library that is based on AT-SPI and can be used by assistive
technologies under KDE).

Please keep in mind that AT-SPI is very likely to become a standard on Unix
systems.

> > Your idea to use DCOP as a way to provide information to an external
> > application is interesting. We had also discussed this possibility, but
>
> I must also add that DCOP offers a very easy to use programming
> environment, requiring close to 0 code to support.
>
> > then thought that full interoperability with GNOME would be of larger
> > benefit for us, since there are already very good assistive technologies
> > for which it would be great to have them compatible with KDE.
>
> 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.
>
Even if there currently are not many assistive technologies that make use of
AT-SPI it makes sense to only have one standard for accessibility
information. If there are two standards the developers of assistive
technologies need either to implement both or they need to choose which one
they support. If one is only for KDE and the other one is for the rest of the
world (currently GNOME applications, Java applications, mozilla and
OpenOffice.org support AT-SPI) it is not difficult to guess which one they
choose, right?

> > We will look at your code soon, if my impression is right, your hacks
> > would fit very fell to our plans to bridge to AT-SPI, as we hadn't
> > dreamed of having QAccessible already usable.
>
> Some of them may be of use, but in general the code that takes a somewhat
> restricted view of UIs (and it often bypasses QAccessible, when it's easier
> to work with the widgets). What does worry me is that the technique used to
> bypass mouse grabs (crucial when dealing with popups) does not seem like
> it'd generalize easily [currently, the plugin intercepts mouse clicks to
> popup menus (it inserts an event filter on accessibility events), and
> checks whether it falls on top of a window with an appropriate WM_CLASS, if
> so, it tells it over DCOP to simulate a mouse event, and squashes it
> locally).
>
Sorry, but I don't get what you mean. If the user clicks on a popup entry, you
do not have to do anything. And when the user clicks on a button in
Klaviatura you only need to call the appropriate
QAccessibleInterface::doAction() method. Or do I miss something?

Gunnar Schmi Dt

P.S.:
Your patch for Qt does not work correctly. When compiling the example programs
of Qt it produces linking errors (I suppose that it did not include
qaccessible_x11.o in the Qt library). I have produced a cleaner patch for Qt.
This patch adds the options -accessibility and -no-accessibility to the
configure script (default is -accessibility). However, that option is not
passed to KDE, so I need to add CXXFLAGS=-DQT_ACCESSIBILITY_SUPPORT and
CFLAGS=-DQT_ACCESSIBILITY_SUPPORT to the calls of the configure scripts of
the KDE parts that depend on QAccessible and its derived classes. Currently
this is only the Klaviatura plug in, but it might become more if we regularly
call QAccessible::updateAccessibility. However, in that case it is better to
add a patch to the KDE Makefile system.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/CozWsxZ93p+gHn4RAh9bAJsGyXwXNgFDgLalnVvU6tqCX119gQCg0ZG+
tD4AGYLlVu/dfltf1Hyz04Y=
=ERrR
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qt_xaccess_concept.diff
Type: text/x-diff
Size: 11251 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-accessibility/attachments/20030708/0dbf9b77/qt_xaccess_concept-0001.bin