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

Maksim Orlovich mo002j at mail.rochester.edu
Tue Jul 8 10:50:21 CEST 2003

On Tue, 8 Jul 2003, Gunnar Schmi Dt wrote:

> 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 

In some cases yes, in some case no. For some widgets using QAccessible
just doesn't make sense -- i.e. activating a menuitem, which is not
generally a widget, is easier to do using the QMenuData API
and not using the generic invoke hook[*]. Actually, for most things I
actually had both versions, but switched to using direct calls for
debugging; I'll probably switch them back today.

*You could say that one could use a custom menu class that doesn't inherit
off it, and you do have a point, and it's easy enough to do the same
through the interface; however, I'd like to think that at least no KDE app
will do it, since otherwise, I'll knock at the responsible party's Gnome,
and make them memorize the QStyle API, all couple hundreds of entries.

> demonstration what will be cleanly possible if QAccessible gets
extended and 
> not a demonstration of what QAccessible can do (or not do).

Yes and no. It also shows that in some cases expanding QAccessible may be
pointless, since the base Qt interfaces and conventions provide what's
needed any way. A side example is copy/cut/paste. Although there is no
base class or anything like that for this, it is in fact possible to
perform those operations on all editable widgets I know off. See
KApplication::cut()/copy/paste -- all they do is invoke certain
conventional slots. Remember, though, that unlike ATK, we can assume Qt. 

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

Yes, that's certainly intended, I am not quite sure of how to best present
it though. Since i.e. some widgets would have to take the focus to an
editable component (i.e. labels with buddies) -- and probably popup the
keyboard, and perhaps try to position it out of the way; while others
would correspond to actual events. 

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

You need those that have little menus attached, like the zoom buttons in

> different between the two? (Or is it because I used KDE 3.1 branch instead of 
> head?)

May be.

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

I think so, although yes, not through interfaces, since ::navigate doesn't
consider parent-child relationships, only directional ones among the

> application programmers view you do not need any other API.

Not quite, since the accessibility application can't generally run
in-process (one generally doesn't want a copy for each app that's run); 
but it needs knowledge about things even outside.

> The only case  where a native API could be helpfull is when writing an
> assistive technology for KDE. 

Well, I would hope that would not be an uncommon case.

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

Please also keep in mind that KDE is not a second class citizen on Unix
systems, but rather a defacto standard. 

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

Actually, it is. They'll likely chose the one that works best with their
programming style and the environment they're comfortable with.

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

Yes. When a popup menu is up, it does a global keyboard mouse grab. That
means all mouse clicks go to the popup (it has something to do with race
conditions, remember X is asycnhrous). So when you click on Klavi, it's
actually the app that gets the click (and QPopupMenu has code that hides
it on any clicks to the outside).  So one either has to break the grab,
which is pottentially damaging since it may break all sorts of assumptions
inside the toolkit, or find a way for the application and the
accessibility provider to cooperate -- i.e. a way to detect that a click
was detected for the accessibility provider, and to tell it through an IPC
layer to handle it. 

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

Hmm, it should work, but it wouldn't be too surprising if I messed
something up with the build. 

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 

I think the way this is supposed to work is that one of the Qt includes is
supposed to define this. IIRC it's qmodules.h + qconfig.h or something
like that. 

More information about the kde-accessibility mailing list