Re: [g-a-devel] AT-SPI, focus leaving and window IDs

[Bill Haneman <Bill Haneman Sun COM>]

I'm going to backtrack a bit to Samuel's original post:

> There are several things which should be added to AT-SPI to my mind:

I believe that all the information Samuel is suggesting and requesting 
is already available in at-spi.  I'll try to explain where...

> - Focus leaving should be reported as well:

There are two aspects of 'focus' here - there is "widget focus", i.e. 
which the individual widget emits, as "focus:" events.  AtkObjects also 
report changes in state, including "state-changed:focus" which changes 
to FALSE when a widget loses keyboard focus.  So the "loss of widget 
focus" is already reported.

There is also the "active toplevel window", which is exposed through 
"window:activate" and "window:deactivate" events.  So when an accessible 
window becomes inactive, at-spi does send notification of this fact (via 
window:deactivate).  So this information is already exposed by at-spi.

At the moment at-spi doesn't emit "window:activate" events for 
"inaccessible" windows.  This could be changed, with a bit of work, but 
it would introduce a dependency on a particular window manager (ie. 
at-spi would require metacity), and I don't think the added value for 
users is worth the added dependency, as gnopernicus already speaks the 
name of the 'inaccessible' application as you cycle through toplevel 
windows with "Alt-TAB".  Any other changes which you'd like to see, for 
instance having gnopernicus announce that the currently active toplevel 
is inaccessible, could be done in gnopernicus without any at-spi changes.

> - It would also be useful to be able to get widgets' X-window ID to
>   better handle focus.

I don't see any useful thing that a screenreader on a _modern_ Xwindows 
platform could do with this.  It's no longer true that all widgets have 
their own XIDs, X-window IDs are now only an internal implementation 
detail and give very little information of value to outside observers.

The only exception to this is in the case of the at-spi "LoginHelper" 
interface, which is used only by specialist applications such as screen 
lock dialogs, password authenticators, and the like, and isn't listened 
to by assistive technologies.  Those highly-specialized applications 
_do_ get involved with the XWindows window stack and window IDs in a few 
cases, and one piece of LoginHelper API does report the XWindow ID of 
one or more toplevel windows, but assistive technologies in general 
should not have any need to get involved with the XServer's window stack 
(furthermore, they are inviting trouble if they do).

regards

Bill

icrosystems Ireland