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