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

[Bill Haneman <Bill Haneman Sun COM>]

Hi Samuel:
> Ah, this is not explicitly written in at-spi documentation, I didn't
> manage to figure it out.
> I would have reported it a similar way as "focus:" events, though...

It would just double the number of focus: related events sent, with 
almost no additional semantic content.

> > 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.
>
>
> Ok, in my case (reading gnome-terminal's terminal widget), that wasn't
> sufficient (since other widgets may get the focus).

I don't understand what you mean by "wasn't sufficient"... do you mean 
that you weren't listening for "window:deactivate" events?

> Providing deactivate and focus-out is just fine to my mind.

Great, so we're agreed here.
> > > - 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.
>
>
> Get the non-accessible application's window title.

I don't think this really works, because the window "title" (as seen by 
the sighted user) isn't reliably available for 'inaccessible' 
applications even if you have the XWindow ID.

For cases where it is, the best place to get the information is from the 
window manager, and you can already find out what the title of the 
currently-focussed toplevel is, without at-spi.  AT-SPI doesn't provide 
information about windows that don't participate in the accessibility 
APIs, because that would make it more difficult to distinguish 
"applications which supposedly are accessible, but aren't working 
right", and "applications which are totally inaccessible".

If you really want the name of the currently-focussed toplevel, you can 
get it via libwnck (as GOK currently does), or you can copy the 
techniques which libwnck uses, because this information is exposed via 
standard XWindows and window manager protocols.  So if you "really" need 
this information for otherwise "inaccessible" toplevel windows, you can 
get it from standard techniques already, rather than from at-spi, which 
is concerned with applications which are actively participating in the 
accessibility protocols.

To go back to a previous question - yes, we *do* expect every 
application should participate in at-spi.  That doesn't mean that 
applications can't be self-brailling or self-voicing as well; it's up to 
the applications and the ATs to negotiate how to coexist.  For instance, 
a self-voicing application should still participate in at-spi so that it 
can work for mobility-challenged users, and so with focus-tracking 
magnifiers, etc.  Possibly we should introduce attributes or 'states' in 
AccessibleObject to hint that an object is 'self-voicing' or 
'self-brailling', but actually I think it's better to expect that 
multiple assistive technologies may be present at all times, and that 
some of them may be 'internal' to the application.  This means that the 
coexistance and resource sharing needs to happen at the service level, 
i.e. the gnome-speech or brlapi or gnome-mag layer.

- Bill