Re: Applications ignoring focus events

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.