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

[Bill Haneman <Bill Haneman Sun COM>]

Samuel Thibault wrote:
...
> I'm not, because brltty doesn't care about toplevel windows, but only
> about terminal widgets. I said "since other widgets may get the focus":
> the user may open some menu, in which case the toplevel window is the
> same, but the widget is different, and as such brltty should leave back
> braille output control to gnopernicus.

For your case it sounds as if listening for 'focus:' and then monitoring 
 'object:state-changed' events on the focussed terminal object is the 
best approach.

> Well, libwnck actually *does* rely on the XWindow ID.

Yes.  But it can get it via other means, it doesn't need to get it from 
at-spi, as you know.

> But actually I wrote that "get title" reply way too fast. This is not
> the point: what we need is at-spi-terms-reading-brltty to know the
> underlying ID of the terminal widget, the one that is given to the
> program running in the xterm in the WINDOWID environment variable.

I'll have to think about this a bit more.

> The problem I'm seeing coming without that information is fbterm/screen:
> For now, fbterm is not accessible, screen is via a shm hack. But on the
> long term, I guess at-spi would be a good candidate to make them
> accessible. However, how would BrlAPI be able to know which virtual
> terminal currently has the focus if this it is not reported somewhere in
> at-spi? 

That piece of information _is_ reported in at-spi, i.e. an application 
can know when it has focus (but of course it knows this anyway).  If 
nothing else, the text-mode braille-aware application should be able to 
know the window ID of its containing terminal widget, from its WINDOWID 
environment.  So it would be the responsibility of the client/terminal 
to tell BrlAPI that it has the focus.

So to me, this seems like part of the interface between a terminal 
widget and its text-mode 'client' (the passing of WINDOWIDs).  But even 
without this, I think that text-mode applications have other ways of 
knowing when "they" have keyboard focus (in other words, when their 
containing widget has X keyboard focus).

So I think perhaps we are worrying about a problem that is already 
solved, we just need to get the terminal emulation folks to point us at 
the existing solution, I am pretty sure that a text-mode application 
should be able to tell when it has focus without having to ask AT-SPI.

regards,

Bill Haneman