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

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

Bill Haneman, le ven 04 mar 2005 17:54:18 +0000, a dit :
> 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.

Yes, we need to: any pseudo-terminal stuff is kernel-related, since it
brings security issues.

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

Asynchronously yes, but in sequence since on the same channel. While
here with the SIGWINCH way, there are two channels: the sequence-safe
which is stdin, and the really-not-sequence-safe which is signals. There
is no sequence safety between them.

Think about a root-launched program running in some user-launched xterm.
There is no other channel between the xterm and the root-program than
the pseudo-terminal. And the only way for xterm to warn the root-program
about things like window resizes is to ask the kernel, via ioctl()s, to
send signals to the root-program (SIGWINCH is just an example, there are
many others: SIGINT, SIGSTOP, ...)

> 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 already did, thanks :)

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

I'm not asking it about coherency: I'm asking "ok, I found that terminal
widget, but I'd like to know its ID because text applications running
in it may tell that they run in it, I need to know whether I should show
*their* braille output". There can't be coherency problems here.

Of course, the focus may have changed in the meanwhile, that's no
problem: at-spi-terms-reading brltty will notice that immediately, and
re-ask for the ID of the new terminal widget.

> In the case of graphical virtual terminals, the authority on focus is
> the X server, not the kernel.

Of course! That's why xbrlapi asks the Xserver. But the kernel is
authority on the relation between an xterm and the text application
running in it. So if you want text applications to be notified when
focus changes, xterm, when notified by the X server that it got the
focus, *has* to pass via the kernel (just because the program to notify
might run by another user).

> I don't believe that the XServer will send key events _prior_ to
> sending the focus change notification.

Of course it won't. And it is easy for it to assert that, since those
events are sent on the same channel.

> 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

Of course! BrlAPI never wanted that.
In BrlAPI's model, applications grab some *tty* braille display (just
like they grab the terminal display by having their controlling tty on
it), be it a virtual linux console or an xterm.

> (just to send braille when, and in most cases only when, the terminal
> is 'focussed').

It may send braille at anytime, just like text application send text at
any time. And the BrlAPI server makes the choice to show it or not, just
like the screen program chooses to display text output or not.

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

Of course.

> So a much simpler model can be used, whereby terminals 
> request access to the braille display _on receipt of a key event_

As I already told, relying on the client to grab the braille display at
the right time is dangerous. gnopernicus grabs the whole VT7 as a
default braille output, but other applications should just output
braille and let the BrlAPI server choose to display it or not, depending
on what the Xserver tells about the focus.

And having such delay seems really wrong to me. So you'll have to press
a key to get the displaying? That's pretty weird. Would it be *so*
difficult for at-spi objects to have an "underlying ID" property?
(be it an X-window object or an fbterm VT or a Microsoft Windows window)

Regards,
Samuel