Re: [Kde-accessibility] Questions regarding AT-SPI and ATK
- From: Brian Cameron <Brian Cameron Sun COM>
- To: gnome-accessibility-list gnome org, gunnar schmi-dt de
- Cc: kde-accessibility mail kde org, vohi trolltech com
- Subject: Re: [Kde-accessibility] Questions regarding AT-SPI and ATK
- Date: Wed, 30 Jul 2003 16:20:30 +0100 (BST)
> From: Gunnar Schmi Dt <gunnar schmi-dt de>
> To: gnome-accessibility-list 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
> X-Spam-Checker-Version: SpamAssassin 2.54 (220.127.116.11-2003-05-11-exp)
> cc: kde-accessibility mail kde org
> cc: Volker Hilsheimer <vohi trolltech com>
> Subject: [Kde-accessibility] Questions regarding AT-SPI and ATK
> X-BeenThere: kde-accessibility mail kde org
> X-Mailman-Version: 2.1.1
> List-Id: For information and discussion about KDE accessibility
> List-Unsubscribe: <http://mail.kde.org/mailman/listinfo/kde-accessibility>,
<mailto:kde-accessibility-request mail kde org?subject=unsubscribe>
> List-Archive: <http://mail.kde.org/pipermail/kde-accessibility>
> List-Post: <mailto:kde-accessibility mail kde org>
> List-Help: <mailto:kde-accessibility-request mail kde org?subject=help>
> List-Subscribe: <http://mail.kde.org/mailman/listinfo/kde-accessibility>,
<mailto:kde-accessibility-request 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
> 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:
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?
The AT-SPI IDL files are good reference for the AT-SPI interfaces:
The AT-SPI c-bindings are documented here:
Other useful tech docs are here:
> 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
> 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
> - -Send those mouse clicks that are not directed to an application window to
> 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
> 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.
] [Thread Prev