Re: _NET_ACTIVE_WINDOW, revisited

[Lubos Lunak <l lunak suse cz>]

On Thursday 21 of July 2005 07:21, Elijah Newren wrote:
> 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."

 I've always understood the last sentence as "activating a window means also 
the following things may happen". Even now thinking of it I still find it 
ambiguous (which might be because I'm not a native speaker, but anyway).

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

 One error in that thinking would be that you'd break anything non-GNOME, 
which you have no control over, and you'd fix something that you have control 
to fix elsewhere. Also for backwards compatibility it might be better if the 
default old behaviour would be the one of "world minus GNOME". Assuming a 
change is really needed, because while I agree with your reasoning about the 
policy, I don't see any reason why _NET_ACTIVE_WINDOW should work like it 
used to in GNOME.

 For example, the minion&king example in the bugreport 
(http://bugzilla.gnome.org/show_bug.cgi?id=166379#c20) is flawed. For 
starters, the minion doesn't come to the palace but he's there all the time, 
and he's in a place assigned to him. If I was that king, told a minion to be 
somewhere and he started running all around my palace and even came to my 
concert hall, he might be unlucky and end up beheaded. Enough of minions, 
let's start discussing windows.

 When I put a window somewhere, I want it to be there, that's why I've put it 
there in the first place. If a user has 3rd virtual desktop called 
'Mail&News', why should KMail ever come to 'Development'? When a window is 
supposed to be activated, it should be activated, and that's about it. It 
might be unminimized, because indeed you cannot activate it otherwise, but I 
don't see a reason why it should move somewhere else.

 What use cases do you have for _NET_ACTIVE_WINDOW also moving a window to the 
current desktop? An example I can think of is e.g. KUniqueApplication, i.e. 
when you have already let's say KControl running, and you're in another 
virtual desktop and you try to launch it again, then it makes sense to move 
the already running instance to the current virtual desktop and activate it, 
but this is not really just activation. This is making the already running 
instance look like it's been just launched, and I don't see any problem there 
with the app also moving the window to the current desktop.

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

 I don't see any race in messages order here, but I see another problem, which 
I mentioned already when requesting that Metacity changes its behaviour. If a 
try to activate a taskbar entry, how do you know to which virtual desktop to 
switch to? If you have just one window for the entry, that's simple. But what 
if the window has a modal dialog, for example?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/