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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
