[Kde-accessibility] Questions regarding AT-SPI and ATK

[Brian Cameron]

> From: Gunnar Schmi Dt <gunnar at schmi-dt.de>
> To: gnome-accessibility-list at gnome.org
> Date: Tue, 29 Jul 2003 20:57:49 +0200
> User-Agent: KMail/1.5.2
> Content-Description: clearsigned data
> Content-Disposition: inline
> X-Spam-Status: No, hits=-0.3 required=5.5 
tests=CLICK_BELOW,PGP_SIGNATURE,RCVD_IN_NJABL, 
RCVD_IN_OSIRUSOFT_COM,USER_AGENT_KMAIL,X_NJABL_DIALUP version=2.54
> X-Spam-Level: 
> X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp)
> cc: kde-accessibility at mail.kde.org
> cc: Volker Hilsheimer <vohi at trolltech.com>
> Subject: [Kde-accessibility] Questions regarding AT-SPI and ATK
> X-BeenThere: kde-accessibility at mail.kde.org
> X-Mailman-Version: 2.1.1
> List-Id: For information and discussion about KDE accessibility 
<kde-accessibility.mail.kde.org>
> List-Unsubscribe: <http://mail.kde.org/mailman/listinfo/kde-accessibility>, 
<mailto:kde-accessibility-request at mail.kde.org?subject=unsubscribe>
> List-Archive: <http://mail.kde.org/pipermail/kde-accessibility>
> List-Post: <mailto:kde-accessibility at mail.kde.org>
> List-Help: <mailto:kde-accessibility-request at mail.kde.org?subject=help>
> List-Subscribe: <http://mail.kde.org/mailman/listinfo/kde-accessibility>, 
<mailto:kde-accessibility-request at mail.kde.org?subject=subscribe>
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by 
dub-mail1.Ireland.Sun.COM id h6TIxUF11887
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> The KDE Accessibility Project is currently elaborating on what is the best way
> to add AT-SPI support to Qt and KDE. Clearly this will be done by using the
> Qt Accessibility Architecture (which currently gets extended by Trolltech).
> However, there are a number of questions that IMO need to get solved:
> 
> 1. What are the exact events that are used in AT-SPI and ATK?

The ATK API is here:

  http://developer.gnome.org/doc/API/2.0/atk/atk.html
  
For example, if you look at AtkText, you can easily see that the events
are text-attributes-changes, text-caret-moved, text-changed, and
text-selection-changed.  The other interfaces have similar information
about events that they support.

> 1. In order to extend their accessibility framework, the Trolltech developers
> need to know which events are used in AT-SPI and ATK and which details are
> used to describe these events. As far as I looked there is no documentation
> about the event types in AT-SPI. In ATK the documentation for the events is
> spread over all interfaces. So far I found the following events:
> 
> Key press, Key release, Children change, Focus change, Property change,
> State change, Visible data change, Selection changed, Column deleted,
> Column inserted, Column reordered, Model changed, Row deleted,
> Row inserted, Row reordered, Text attributes changed, Text caret moved,
> Text changed, Text selection changed
> 
> Is this list complete? Which information describing those events is included
> in these events?

Refer to:

  http://accessibility.kde.org/developer/atk.php

The AT-SPI IDL files are good reference for the AT-SPI interfaces:
  
  http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=at-spi/idl
  
The AT-SPI c-bindings are documented here:

  http://developer.gnome.org/projects/gap/tech-docs/at-spi-docs/book1.html
  
Other useful tech docs are here:

  http://developer.gnome.org/projects/gap/tech-docs/
  
> 3. One of the KDE developers wrote a prove-of-concept application that uses
> the current Qt Accessibility Architecture. This application is called
> Klaviatura and serves for two purposes: It can be used to remotely control
> the menu bars, tool bars and popup menus of KDE applications, and it contains
> an on-screen keyboard. Technically Klaviatura consists of a plug-in for Qt
> and an external application. Both parts communicate with each other via DCOP.
> 
> When writing this application the developer found that applications often make
> mouse grabs when showing pop up menus. If then a mouse click was intended to
> go to an assistive technology it will be used by the wrong application.
> 
> In Klaviatura this problem is solved as follows:
> The plug-in intercepts the event handling in order to be able to process mouse
> clicks before the application processes them. If the mouse click was directed
> to a window of Klaviatura that mouse click is intercepted and sent to the
> Klaviatura application (via DCOP). Otherwise the mouse click is not
> intercepted (and therefore will be processed by the application).
> 
> There are multiple possibilities for solving this issue in AT-SPI:
> - - Avoid popup menus (and other things that require mouse grabs). This is not 
a
> good solution as it interferes with the current user interface design of many
> applications. Not showing a popup menu means either less functionality or (in
> the case that you need an assistive technology to activate an entry in the
> popup menu) less usability.
> - - Do the popup menus without mouse grabs. This is not a good solution as pop
> up menus need mouse grabs in order to work properly.
> - -Send all mouse clicks to the ATs first and ask for a permission to process
> them.
> - -Send those mouse clicks that are not directed to an application window to 
the
> ATs and ask for a permission to process them.
> 
> The last two possibilities sound acceptable to me. I am not sure which is the
> better one. Many assistive technologies might not be interested in processing
> all mouse clicks, but there might be some few ATs that need top process them
> all.
> 
> Solving this problem will be important as some KDE developers will otherwise 
> have objections against AT-SPI.

I think the forthcoming Xserver extension that Peter mentioned should help
address this issue.

> 4. Some KDE developers have concerns that AT-SPI is not powerfull enough. In 
> order to convince them that we will be able to extend the protocol if 
> necessary we need support for custom interfaces.

Yes, we are delighted to work with you to extend ATK and AT-SPI in ways
that meet accessibily needs for KDE.

Brian