Re: _NET_ACTIVE_WINDOW, revisited

[Billy Biggs <vektor dumbterm net>]

Elijah Newren (newren gmail com):

> [...] 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.

  While the timestamp is helpful, the WM should be able to do something
reasonable even if the timestamp is 0.  SWT uses the current event time,
which would be 0 if someone deferred work to an idle handler or similar.
In our current release, I changed this to use the last user event time
if the WM name is "metacity" because this was causing problems
otherwise.  Still, this doesn't help older versions of SWT, which will
continue to be used for quite some time, so I'd rather they not break
too badly. :)

> 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).

  The timestamp code in gtk_window_present() is new for GTK+ 2.6.3, so
that's a very recent change.  We stopped using gtk_window_present() in
late 2003 because it was causing problems, I suspect because of the
gdk_window_show() was doing more work than we expected.

> 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.

  I think the WM should map _NET_ACTIVE_WINDOW requests to demands
attention if they conflict with the policy.  I believe kwin implements
this well, so this suggests that there is a reasonable middle ground.

  -Billy