Re: Applications ignoring focus events
- From: "Dana Jansens" <danakj orodu net>
- Cc: wm-spec-list gnome org
- Subject: Re: Applications ignoring focus events
- Date: Thu, 17 May 2007 17:38:42 -0400
On 5/17/07, Havoc Pennington <hp redhat com> wrote:
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
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
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.
] [Thread Prev