On 8/17/06, Bill Haneman <[EMAIL PROTECTED]> wrote: > On Wed, 2006-08-16 at 19:45, Elijah Newren wrote: > ... > > Hi Elijah: > > I appreciate the underlying logic behind the focus-stealing prevention, > and in particular the oft-cited case where focus moves out of a password > field during authentication. > > It does however cause some serious problems for AT-SPI. > > We basically cannot transfer timestamps with our doAction requests, > API/ABI-compatibly.
Ouch. That doesn't sound good. > The best we can do, I think, is have the ATK implementation code (in > libgail) call gdk_x11_window_set_user_time() on the relevant toplevel. > However, we have to get an appropriate timestamp from somewhere, and > unfortunately it cannot be gotten from AT-SPI. So libgail has to > somehow obtain a timestamp for "the current time" when A(TK receives the > request. Unfortunately the canonical CURRENT_TIME macro in X11 is just > '0' which fails to solve the problem, I think. Yes, that's correct. GDK_CURRENT_TIME/CurrentTime (gdk & X names for the same thing) are not useful in cases like this. Bit of trivia: In fact, since 0 is the only known invalid timestamp, the spec makes use of this to say that it should be treated as a specialized "please do not focus me at all" hint. So, this is quite the opposite of what you want. Short rant: CurrentTime is also buggy in a wide range of other cases (even when the timestamp is meant for a message to the Xserver instead of to the WM), as its use leads to subtle and nasty race conditions. I'd be willing to guess that most uses of it are wrong in application/toolkit/window manager codes. > Would the value returned from gdk_x11_get_user_time() do the trick? Short answer: No, it would result in no change whatsoever from the current behavior, since this is precisely what gtk+ already does. Long (explanatory) answer: gdk_x11_get_user_time() merely returns display_x11->user_time, which stores the last time gtk+ was able to detect that the user interacted with that particular process. gdk_x11_window_set_user_time() exists to allow app authors to update the timestamp on a window when there's some kind of special user interaction with an application that gtk+ has no way of being aware of. (Examples of "special interaction": single-instance applications forwarding requests to other instances to open a window, metacity handling a keybinding and forwarding it to the gnome-panel to have it show a "Run application" dialog, and apparently AT-SPI/ATK...). gdk_x11_window_set_user_time() happens to also update display_x11->user_time as a side effect. To fix this: We need some way of getting the timestamp from the sender process to metacity. You actually don't need to request the application author to supply it; you could just call gdk_x11_display_get_user_time(). But we do need to either get it sent to the other process, or get it sent to the WM in some manner that also lets the WM know precisely which window (or windows) it will be appilcable for. The latter is pretty problematic. It means we need to extend the spec so things will work with other window managers as well (e.g. KWin). But there's an even bigger question of whether the latter option is even feasible; does the sending process really know which windows will be launched in response to an action? We may need to dream up some creative ways of trying to get the timestamp from the sender to the receiver inside AT-SPI (e.g. set a property on certain windows saying they can receive additional or modified messages, and have AT-SPI detect such, and then have AT-SPI send additional or modified messages) Hope that helps, Elijah _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
