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 _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
