Re: _NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

On 7/21/05, Lubos Lunak <l lunak suse cz> wrote:

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

Yes, and it lists "moving [the window] to the current desktop" which
is what we want to do.  In fact, the writing suggests that whoever
wrote the spec expected that this would be the more common case since
it only listed "changing to the desktop the window is on" in
parentheses.

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

If changing back would be considered "breaking" non-Gnome things, then
they were already broken for forever.  We only snuck in the change
just barely before Gnome 2.10, which is fairly new and still having
point stable releases (i.e. we can still revert so that official 2.10
behavior is still the old one).  And, I disagree with the claim that
it would break anything.  I don't see moving windows selected in a
window list[1] or window selector[2] to the current workspace as an
invalid policy.  In fact, gnome-panel/libwnck have a preference valid
when windows from all workspaces are shown in the window list, which
allows the user to choose whether selecting a window from the window
list will move it to the current workspace or move the user to the
workspace where the window is.  (However, this is a stupid preference
in my opinion--I don't see how the value outweighs the costs and we
should just make it always move the windows to the current workspace).
 In each and every 2.x.y release of Gnome (including the recent ones
where metacity changed to your behavior), the default is to move
windows to the workspace where the user is.

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

Sounds like you're arguing your world view for the policy you have
chosen.  Sounds like a perfectly fine policy.  It doesn't sound like
the only valid policy.

> What use cases do you have for _NET_ACTIVE_WINDOW also moving a window
> to the current desktop? 

I think your view of the minion analogy is fine, but we view it
differently.  The king should be allowed to request the minion to come
to him where he and his guests (other windows the user is working
with) are currently at.  The king should not have to go and get the
minion and bring him back to where the guests are.  The king should
not have to bring all the guests with him to the minion.  Even if the
king doesn't have guests, maybe he just likes his little throne and
doesn't want to be bothered to move.  If the minion doesn't want to
come when beckoned, he should be beheaded.

Yours is a palace where the King is a control freak that wants to
place everyone in certain places and remembers where they all are and
doesn't want them interacting with each other or seeing something they
shouldn't.  Ours is a palace where the king is a lazy leech that
enjoys what he is doing with the company he has, doesn't want to be
bothered with remembering where everything and everyone is, and wants
to beckon people to him.

Dropping the analogies in order to be clear: The user is likely on a
given workspace for a reason.  They are likely interacting with
several windows.  If we make _NET_ACTIVE_WINDOW move the user to
another workspace, then they have to do the additional step of
manually moving the activated window back to the other workspace in
order to be able to use both the activated window and the windows that
had been on their original workspace.  That's a pain.

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

I agree that according to your policy for activation it makes sense to
be able to distinguish activation-for-newly-launched-window and
activation-for-existing-window.  I believe an addition to the spec to
make it easier to distinguish the two would be useful, though our
policy would be to treat both cases by bringing the window to the
workspace where the user is.

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

I don't see how there's any problem with Metacity here.  If a user
somehow places a modal window and its parent on different workspaces,
and then clicks on the parent window, then we bring the modal window
to the workspace where the parent is and focus/raise it instead.  Why
should the _NET_ACTIVE_WINDOW message case be any different than the
user clicking on the window?  We don't see how it should, so we just
bring the modal window to where the parent window is and have it
focused/raised.

Also, note that it's only for the window selector (well, other than
the stupid preference for the window list that I already mentioned
needs to be nuked) where we currently allow a
switch-workspace-then-activate.  See [1] and [2] for reasons. 
However, given that this does feel like a third kind of activation, I
do see value in adding some kind of
activation-from-pager-that-is-workspace-aware hint to go along with
the activation-for-newly-launched-window and
activation-for-existing-window hints mentioned above.

In addition to not seeing your particular case as a problem for our
policy, I can't see how to possibly get correct behavior with your
policy.  Since your policy is to not change any window's workspace
when activating, I don't see any option other than one of the
following four cases:

a) Change to the workspace where the parent window is.  Notice it has
a modal window.  Change to the workspace where the modal window is and
focus/raise it.  Results in ugly flickering.

b) Recognize that the parent window has a modal child, change to the
workspace  where the modal window is and focus/raise it.  Result: Why
in the world can't the user see the parent window for which they are
being asked a question in the modal dialog?

c) Change to the workspace where the parent window is and just sit
there.  Result: Why can't the user interact with the window?

d) Break policy.  Either move the child to where the parent is and go
there, or move the parent to where the child window is and go there.

I personally don't like any of those options.


Summary: I don't see how our changing back would break anything.  I
think not being allowed to change puts policy into the spec that will
cause inconsistent behavior among apps.  I believe it may be valuable
to add activation types in the spec (such as
activation-from-pager-that-is-workspace-aware,
activation-for-newly-launched-window, and
activation-for-existing-window).  I might still be in error--please
point out any mistakes that I have made.

Elijah


[1] The window list is a taskbar applet with lots of buttons, with one
window icon/title being shown in each; clicking on a button activates
the given window.  In the current Gnome implementation, it only shows
windows on the current workspace by default, and when windows from all
workspaces are shown they are not grouped according to workspace.

[2] The window selector is a taskbar applet with a single icon. 
Clicking on it brings up a menu that lists all windows on all
workspaces, and the windows are grouped by workspace.