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

[Gunnar Schmi Dt]

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

Hello,

First of all I want to thank you for your great work in writing a 
demonstration application for QAccessibleInterface. I hope my last mail did 
not sound like critizism. Currently I am buzy at university and additionally 
I currently write papers for my two talks at the KDE developer's meeting. 
These papers are due on the 16th, so I don't think I will have much time to 
look at your application before.

On Tuesday 08 July 2003 15:50, Maksim Orlovich wrote:
> On Tue, 8 Jul 2003, Gunnar Schmi Dt wrote:
> > [...]
> > 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.
> [...]
Sorry, I don't understand what you mean with 'generic invoke hook'. However, I 
would say that it might be easier for an assistive technology to always use 
methods from QAccessibleInterface. In that way you would not need special 
code for menu bars etc. Off course that implies that each menu item would 
support actions like show() (if it has a sub menu) and activate(). The 
current version of QAccessibleInterface does surely not have enough features, 
but from what I heard Trolltech is currently working on that.

The point is not that it is "wrong" to use explicit knowledge, but it is 
impossible to know all the widgets that might exist in Kde or Qt based 
applications. The only way for third party applications to make their widgets 
fully accessible is to create a subclass of QAccessibleInterface for their 
widgets. This means that QAccessibleInterface needs to contain all needed 
functionality.

> > 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
> Konq.
> [...]
There you are right. The problem are not sub menus but delayed sub menus which 
have two 'actions': one action that is triggered by a simple click and the 
other is to show the popup. This is one example where QAccessibleInterface 
needs to be extended. However, this problem does also exist in Qt.

> > 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
> items.
>
Maybe this is an other example where QAccessibleInterface needs to be 
extended. Did you try to set the focus to the parent widget (method 
QAccessibleInterface::setFocus(int control))?

> > 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.
>
Maybe we do have a misunderstanding here. Of course assistive technologies 
need an API other than QAccessibleInterface. What I wanted to say is that the 
typical KDE application programmer (i.e., someone who writes for example an 
accessible game) does only need to know about QAccessibleInterface.

> > 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.
>
Yes, indeed ;-)

> > 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.
> [...]
Sure, KDE is one of two standards (and I personally develop for KDE). Half of 
the Unix world uses KDE, the other one uses GNOME. And there are applications 
that are neither KDE nor GNOME.

> > 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).
> [...]
Hm, I'm not sure how to solve this. It is a problem with your specific 
assistive technology, so solving this in every single application does not 
look right to me. I think it is a general problem that also happens to other 
toolkits. For demonstration purposes it might be ok if we just live with the 
mouse grab.

> > P.S.:
> > [...]
> > I have produced a cleaner patch for Qt.
> > [...]
>
> 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.

I based my patch on a mail from a Trolltech developer 
(http://lists.kde.org/?l=kde-accessibility&m=103847617809571&w=2).

Gunnar Schmi Dt
- -- 
Co-maintainer of the KDE Accessibility Project
Maintainer of the kdeaccessibility package
http://accessibility.kde.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/Cu6nsxZ93p+gHn4RAryBAJ9rH0lD362eTB1GTr2ZYZgfQcaX2gCgr+Tp
NtaNBUbKvZv9Wau6D2zvmLg=
=UNiY
-----END PGP SIGNATURE-----