_NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

Hi guys,

Sorry to respond late (by about two years), but we have a problem.  Lubos sent
http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00062.html
about whether _NET_ACTIVE_WINDOW should preclude switching the
window's workspace to the current one, and then filed
http://bugzilla.gnome.org/show_bug.cgi?id=128380; we made the
requested changes, but we feel that it was in error.

In particular, the activation section of the spec explictly states (as
pointed out to me by Matthias):
"In the X world, activating a window means to give it the input focus.
This may not be possible if the window is unmapped, because it is on a
different desktop. Thus, activating a window may involve additional
steps like moving it to the current desktop (or changing to the
desktop the window is on), deiconifying it or raising it."

So we feel that the spec doesn't prohibit switching of the workspace
of a window in order to activate it, and further that if the spec were
to specify policy in this manner it would cause inconsistency among
applications[1].  So we intend to soon switch back to having Metacity
change a window's workspace to the current workspace when receiving a
_NET_ACTIVE_WINDOW message, unless someone can point out an error in
our thinking or some large problem.

We may well need a separate hint for moving to a given workspace and
activating a given window on that workspace (for pagers), which was
the issue that brought this all up in the first place.  (Though
perhaps _NET_CURRENT_DESKTOP + _NET_ACTIVE_WINDOW is good enough as
long as we don't worry about races in message order?)

Elijah



[1] The reason this would cause inconsistency among applications is as follows:

- toolkits are likely to make a simple "activate this window of mine"
API, which will most likely use net-active-window since the
description matches

- Some WMs like the policy of bring-the-user-to-the-window when an app
requests one of its windows to get activated; Gnome prefers
bring-the-window-to-the-user in such cases[2].

- Gtk+ (which Gnome uses) notices that net-active-window has policy
hardcoded, and the "wrong" one (according to Gnome) specified.  So it
works around it.  Other toolkits that like the hardcoded policy don't.

- Apps using gtk+ always have their windows come to the user; apps
using other toolkits always have the user warped to their windows.

That's just really, really weird.  WMs should specify policy, not
toolkits and apps.

[2] A couple different handy explanations of why:
http://bugzilla.gnome.org/show_bug.cgi?id=166379#c17
http://bugzilla.gnome.org/show_bug.cgi?id=166379#c20
http://bugzilla.gnome.org/show_bug.cgi?id=166379#c22