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

[Maks Orlovich]

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


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

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

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

-Maksim