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

[Samuel Thibault <samuel thibault ens-lyon org>]

Hi,

I reordered things for (hopefully) easier reading.

Bill Haneman, le ven 04 mar 2005 13:07:30 +0000, wrote:
> >>>- 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.

That's the only ID we can rely on about X applications (including
inaccessible ones).

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

But compare what ? An inaccessible application doesn't register itself
in at-spi (and there will always remain inaccessible applications in the
world). If the register doesn't provide X-window ID, there is no way to
compare accessible application windows and inaccessible application
windows.

> the current implementation is 90% correct because gnopernicus 
> does not send braille commands when non-at-spi-participating 
> applications are focussed.

Well, it stops sending braille output, but that is not sufficient to
distinguish between the case when the current accessible application's
widget doesn't change, and the case when the current accessible
application actually lost the focus.

So that the user doesn't know whether the application is hung or just
lost the focus. Yes there are the speech events, but in some conditions
one doesn't want to make any noise, and having headphones just for this
is a pity. Wouldn't it be just fine that gnopernicus at least print the
inaccessible application's window title in such case? (In which case it
needs the XID to get the window's title.)

> >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,
> 
> I doubt this at least for graphical applications.

Why? Should applications always use at-spi to provide braille output?
Couldn't they elaborate their own braille output, probably really much
better than just providing the widget hierarchy?

Well, they could just export one "text" widget in which they put the
text to be displayed, but that's really poor. Does at-spi let them get
usual braille key presses for instance?

In some cases like a particular-braille-device-oriented editor for
instance, that editor will probably want to get really good control on
the braille device (including braille device specific features), and for
this at-spi doesn't seem suited. And that editor may have a graphical
ui.

> >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).

Ok, I can trust you, but I am talking about focus issues.

> I think that brlapi itself is the right place to put any API designed
> for shared access to such a resource,

Yes, that's its purpose.

> If on the other hand, the goal is to avoid "overwriting" the output of
> one client with another,

Yes, that's the point.

> there is no reason why brlapi clients would not be 
> advertised as 'accessible'.

So you are asking for every BrlAPI clients (even text-mode clients) to
use at-spi?? And how can they provide the "focus-in" event?? They run in
an xterm, and the only thing they know about the world is the pty, and
the XID of the xterm (thanks to the well-know WINDOWID environment
variable). Well, they could indeed try to connect to the X display and
snoop focus on the xterm window, but that's much painful for just
text-mode applications!

What we propose with BrlAPI is that the BrlAPI application can give the
XID to the BrlAPI server, and the background-process xbrlapi (or even
the X server itself, if extended for) tells the server which X window
currently has the focus. Then BrlAPI can know whether to show the BrlAPI
application output, or, as a default, gnopernicus output, just like it
does on the text console between BrlAPI applications and brltty's
output. *This* already works fine.

> If the current brlapi interfaces don't allow for multiple simultaneous 
> clients

It *does*, but if neither gnopernicus nor at-spi-xterms-reading-brltty
gives ways to know which, between gnopernicus's and brltty's output
should be displayed, BrlAPI simply can't magically guess it.

> >>> 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.

Indeed, that's precisely what brltty does, so at-spi reading does work
fine between gnopernicus and brltty. But if the focus switches from a
at-spi terminal to a non-accessible application, brltty does not get any
event, so that it doesn't know that it should leave braille output
control to gnopernicus (which would display "non-accessible application"
or the window title).

Brltty *could* tell BrlAPI which X-window it is reading, to let BrlAPI
handle this problem, but it can't for now because it can't get the XID
of the at-spi terminal.


Well, to conclude and to be quite franc, I was really astonished that
there not be any focus-out event in at-spi, while both X-Window and
Microsoft Windows have.

Regards,
Samuel