Re: _NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

On 7/26/05, Billy Biggs <vektor dumbterm net> wrote:

>   In SWT, if the application does setFocus() on a widget, we first call
> gdk_window_focus() (_NET_ACTIVE_WINDOW/XSetInputFocus wrapper) on the
> window belonging to that widget.  Since many WMs do not have focus
> stealing prevention, we only call this if we think one of our windows
> has focus.  Due to races and bugs, sometimes that check is wrong, and we
> call gdk_window_focus() more frequently.  Depending on the situation and
> the version of Eclipse, the timestamp in the request may be 0.
> 
>   setFocus() is used frequently,  For example, it assigns focus to the
> correct widget when you open a dialog.   Every time a dialog appears in
> an SWT application, a _NET_ACTIVE_WINDOW request is therefore emitted.
> 
>   We're basically using _NET_ACTIVE_WINDOW as an assert to ensure that a
> window has focus,   Usually, we hope it does nothing, but in the case
> where the a find dialog calls setFocus() on the text area of a
> particular editor window, we hope it works.
> 
>   Elijah: you are correct that the bugs we have occur when Eclipse
> incorrectly believes it still had focus.  However, given the way we use
> _NET_ACTIVE_WINDOW, I would still prefer a weaker definition.  It's much
> safer to have a request that silently fails or simply sets a demands
> attention hint if the WM decides it's not appropriate than to have
> windows move desktops.

Yep, Lubos definitely identified this problem (Thanks!)

Billy: I agree, we need to have the request set a demands attention
hint when the activation request is not appropriate.  Metacity has
that functionality.  However, the only way the WM can decide if it's
appropriate though, is to know when the user caused it to be
activated.  By giving a timestamp of 0, you aren't providing the
requisite information and are putting the WM in a position where it
can't decide the appropriateness of the call.  We could either deny
all such requests or accept all such requests, but we can't be smart
about picking and choosing without more information (and we choose to
accept all such requests because older versions of the spec did not
have a timestamp field and we're trying to be backward compatible for
older clients).

I'm also surprised that you are using gdk_window_focus().  Why are you
using that instead of gtk_window_present()?  gtk_window_present() is
basically a wrapper for gdk_window_focus() but it also handles the
case that the window is withdrawn (meaning that the WM wouldn't know
about it) and it also is smart about timestamps for you (it figures
that the window was probably being activated due to the most recent
user interaction with that application--something that works perfectly
here).

Note, though, that this issue is a problem regardless of the desktop
switching policy chosen by the WM for _NET_ACTIVE_WINDOW.  If the
window switches workspace, then the user is surprised that some window
randomly appears and steals the focus (and perhaps obscures the
windows they were working on).  If the window doesn't switch
workspace, then the user is surprised to have all their windows ripped
out from under them and getting sent to another desktop.  In both
cases, the user potentially sends keystrokes to a program they didn't
expect.

Hope that helps,
Elijah