[Kde-accessibility] On Qt accessibility and a on-screen
Gunnar Schmi Dt
gunnar at schmi-dt.de
Tue Jul 8 19:17:35 CEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
> > 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
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
Maybe this is an other example where QAccessibleInterface needs to be
extended. Did you try to set the focus to the parent widget (method
> > 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
> > 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
Gunnar Schmi Dt
Co-maintainer of the KDE Accessibility Project
Maintainer of the kdeaccessibility package
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-accessibility