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

[Bill Haneman <Bill Haneman Sun COM>]

Samuel Thibault wrote:

> > That already happens. The way I realize I have started an app that
> > isn't accessable is no speech from Gnopernicus. Using alt-tab to cycle
> > through windows will announce the title of the window containing the non
> > accessable app.  Using this, it's easy to switch back to the window and
> > close the app using alt-f4.
>
>
> That's quite painy.

A client can compare the focussed window object with the registered 
accessible applications and determine when an 'inaccessible' application 
has been focussed, already.

What do you want the screen reader to do in this case which it is not 
already doing?

> And one can't assume that every application running on X-windows will
> use at-spi to provide its braille output: it may directly provide it to
> BrlAPI, in which case gnopernicus needs to know when to give braille
> access back to other BrlAPI applications.

I doubt this at least for graphical applications.  As long as 
gnopernicus is using brltty I don't see any conflict here, unless 
there's something I don't understand about brltty which prevents its use 
by multiple clients.

> > >  It would also permit to launch several at-spi readers: brltty for
> > >  instance now has an at-spi driver so as to be able to read xterms. But
> > >  it needs to know exactly when the focus is on a terminal widget, in
> > >  order to produce display only when needed.

This information is also already available in at-spi.  The listening 
at-spi client can determine when focus is in a terminal widget as 
opposed to some other kind of object, via Accessibility_ROLE_TERMINAL.

> By 'xterms', I meant gnome-terminal for instance. Other xterms should be
> made at-spi accessible as well in some future.
>
>
> > > - It would also be useful to be able to get widgets' X-window ID to
> > >  better handle focus.

I disagree; I don't know of anything that the XID helps with here.

> I mean, for at-spi screen reader, that would be a useful information to
> better match at-spi representation of the running session and the actual
> X-window windows tree.

The screenreader NEVER sees, or cares about, the actual X-windows window 
tree.  That tree does not prove useful to assistive technologies in this 
environment (for reasons which would take a long time to explain).
> > X-windows is usually the general name for the GUI on Unix systems.  If
> > the widget isn't created using a tool kit that supports at-spi, there's
> > not much that can be done.
>
>
> Yes there is: it may directly provide its braille output to BrlAPI. 

Certainly - but we expect ALL applications which care about 
accessibility to participate and cooperate in the at-spi environment.

> But
> this issue is more related to the first point I had: since gnopernicus
> don't tell to BrlAPI which windows it takes care of, it should
> explicitly leave braille display whenever the focus gets on a at-spi
> inaccessible widget (but BrlAPI-accessible widget, so braille-accessible
> in the end).

I think that what is required here is some explicit API between BOTH 
parties whereby brlapi can be shared, it does not make sense for 
gnopernicus to assume that "non-at-spi participant" means potential 
brlapi client, this is wrong on two counts.  Most inaccessible apps 
won't use brlapi, and there is no reason why brlapi clients would not be 
advertised as 'accessible'.

If the current brlapi interfaces don't allow for multiple simultaneous 
clients, then I'd consider this a flaw in brlapi.  If on the other hand, 
the goal is to avoid "overwriting" the output of one client with 
another, the current implementation is 90% correct because gnopernicus 
does not send braille commands when non-at-spi-participating 
applications are focussed.  I think that brlapi itself is the right 
place to put any API designed for shared access to such a resource, i.e. 
a client should be able to temporarily request access to a braille 
display (via a lease, or token, or some such), and another client should 
be able to request pre-emptive access to a braille display which is 
already in use by another client (for instance to give an important 
warning message, etc.).

> Regards,
> Samuel

regards

Bill