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

[Bill Haneman <Bill Haneman Sun COM>]

Samuel Thibault wrote:...
> Such way works: if and only if the program is interested with terminal
> size, it can handle the SIGWINCH signal, which will be raised whenever
> terminal size changes. This is asynchronous, that's no issue here. For
> focus, this *is*: if the signal arrives a bit too late (it will in many
> situations), the focus gets wrong.

OK, we're getting in very deep here.

But note that virtual terminals in the X world are getting their 
keyboard events asynchronously too, via X, by the same mechanism as the 
focus-related events.  So I don't think that the latency issue holds, as 
it has already had to be solved for other reasons (i.e. focus must be 
notifified before the key events arrive, etc.).  In other words, I am 
confident that this is a solved problem already (focus and key-event 
coherence).  There is a lot of text in the Xlib programming manual about 
how this relates to keyboard grabs, etc. if you really want to dig.

I am really not convinced that we have to get the kernel more involved 
than it already is.  In any case I don't think having the XID helps 
much, if at all.  Note also that at-spi communications are less coherent 
/ more asynchronous than X events, so if you are worried about 
coherence, at-spi won't help you that much here.  In the case of 
graphical virtual terminals, the authority on focus is the X server, not 
the kernel.  I don't believe that the XServer will send key events 
_prior_ to sending the focus change notification.

My gut reaction here is still that the right model is for these 
terminals, especially in the mixed graphical and console environment, 
not to grab the braille display at all (just to send braille when, and 
in most cases only when, the terminal is 'focussed').  The Xserver and 
kernal are responsible for moderating the various kinds of keyboard 
focus, and a virtual terminal will not receive key events when it isn't 
focussed.  So a much simpler model can be used, whereby terminals 
request access to the braille display _on receipt of a key event_, since 
any key event signals that focus has been gained.  The case that this 
doesn't handle so well is that of scrolling terminal output (as opposed 
to input), but in that case the virtual terminal will indeed be notified 
that it has focus (via the X events already mentioned), and it matters 
little if the client-switch to the braille display has a small latency 
since the whole business of monitoring scrolling output is inherently 
'asynchronous' (insofar as there is no control over which text "passed 
by" while the terminal was not in the foreground).

- Bill

> The only reliable way to get the focus is to ask for people who have it:
> the kernel for virtual terminals, fbterm and screen for their terminals,
> the Xserver for X, windows for Microsoft Windows.

Bill Haneman