On 5/17/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Hi, > > Dana Jansens wrote: > > One possible solution to all of this would be to demand that > > applications ignore all focus events, and instead only use the > > _NET_ACTIVE_WINDOW hint to determine if they are focused or not. That > > should really be implemented and enforced somehow at the toolkit > > level, though. > > > > Thoughts anyone? > > I think what apps may need to do is distinguish X Window System focus > from user-visible window focus. You can get the X Window System focus > reliably from the X events, and user-visible window focus from > _NET_ACTIVE_WINDOW. > > Metacity iirc basically does this, sometimes it will draw a window frame > as focused even though it does not have X focus. > > It is a bit bad for every app to listen to PropertyNotify on > _NET_ACTIVE_WINDOW though (I think - most apps don't get PropertyNotify > on root window already, do they?), so it might be nice to have another > hint or client message that the WM uses to signal "is the focused > toplevel as displayed to the user" where this is separate from the X > concept of "will in fact get keyboard events" > > In some cases I think bugs here may just be that the X focus events are > _hard_ to properly use; I think Owen had to try several times to get it > right in GTK, and I think it took me a while to get right in metacity > also. This is something a toolkit could simplify for the app layer > (though GTK does not I don't think). > > For a long time gnome-terminal would keep blinking the cursor when > unfocused since it's hard to get this right. > > Apps do need to track actual X focus for some purposes though, such as > showing a focus indication on text boxes, and the danger with a separate > hint is that apps could try using it for the wrong purposes and end up > with worse races or bugs than they already have. > > Certainly part of the existing problem is that the whole focus situation > is just complicated (GTK compounds it on the GtkWidget level, too), and > so it's not clear that making it more complicated will help in practice, > it might just pile on the confusion even if it theoretically makes > something easier.
It sounds like, at the least, toolkits need to provide focus status (through events or polling) differently to windows than to widgets within them. For widgets, a Grab-type focus event should count. But for top level windows, they need to be more intelligent about it, however that may be done: through another hint/message, or possibly through NotifyNormal and NotifyWhileGrabbed only. I agree that watching the root window property would be bad. It would be like the user_time (vs user_time_window) problem, causing applications to wake up when they didn't need to. _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
