Re: _NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

On 7/25/05, Lubos Lunak <l lunak suse cz> wrote:
> On Sunday 24 of July 2005 22:46, Elijah Newren wrote:

<snip>

> > think about other policies that it needed to handle.  Sure, someone
> > might point out that apps could specify _NET_DESKTOP_VIEWPORT as well,
> > but that would be missing the point.  Why do apps have to do all this
> > work?  Why are apps specifying policy?  What if new kinds of UI are
> > introduced later to supplement or replace workspaces and viewports?
> > Do we have to update all apps to make them specify the right policy at
> > that point?  And how in the world do we ensure uniformity across apps
> > so that behavior is consistent?
> 
>  Certainly not in saying "_NET_ACTIVE_WINDOW message has actually a very 
> vague meaning and the WM is free to do whatever it wants", which you seem to
> prefer.

Huh?  That doesn't make sense to me.  We don't specify how WMs must
handle _NET_WM_WINDOW_TYPE_DIALOG windows.  Some WMs don't decorate
such windows; others do.  Some may feel they should appear in the
alt-tab list; others don't.  There's a whole list of properties WMs
are free to associate with this--it conveys a semantic property type,
not a set of policy rules.  This enables uniformity across apps
because apps don't specify the policy.  Sure, the behavior of those
apps are different when under one window manager than another, but
under a given window manager all such windows from all apps regardless
of the toolkit they are implemented with behave the same.  That's the
goal.

_NET_ACTIVE_WINDOW is similar.  Different environments want to provide
different activation policies.  Having it be vague, i.e. only convey a
semantic action type, is _exactly_ what allows a given window manager
to provide consistent behavior for all apps regardless of the toolkit
they were developed with.

<snip>

>  Frankly, it didn't even occur to me somebody would actually like windows to
> change their desktop just as a result of activation. The basic idea behind my
> reasoning is "don't affect the window (more than necessary)". If the window
> is minimized, it has to be unminimized, because otherwise there's simply no
> way to activate it. But moving the window to another workspace is a change
> that's not necessary, that's changing a property of the window that wasn't
> requested to be changed. That's why I also think _NET_ACTIVE_WINDOW should
> primarily only try to affect the activity state of the window and nothing
> else.

The idea behind our reasoning was actually very similar.  We treat
_NET_ACTIVE_WINDOW as a "do what's necessary to activate this window"
request from the user and we feel it is important that we "don't
affect more than necessary to get the window activated."  So, how do
we interpret that?  Focusing the window seems an obvious need for
activation.  The user didn't explicitly request the window to be
unminimized, but it falls under "do what's necessary to activate this
window".  If the window is a transient, we unminimize its parent(s),
as we feel the window doesn't make sense to be shown alone.  We leave
show_desktop mode if it is on (since show desktop means windows aren't
shown).  We unshade the window if shaded (doesn't make much sense to
us to activate the titlebar only).  Raising the window is sort of
similar to unminimizing, though it may depend on another preference
(one that we currently don't support anyway, so raising
unconditionally is fine for us for now)[1].  We don't support
viewports and thus don't have to worry about them.  Now, if the window
is on a different workspace, there are two choices:
  - change the window's workspace
  - unmap a bunch of unrelated windows (i.e. windows from different applications
    than the window-to-be-activated) and map a lot of other unrelated
    windows
The user didn't request anything to be done with all those other
applications, therefore changing the window's workspace provides the
least amount of change.

<snip>

> - It is noticeably simpler for the app just to try to activate its window then
> to detect in which state it is and act accordingly.

I agree; I don't see why an app should ever need to detect its state
before trying to activate one of its windows.

> What if it is active and it only wants to activate its other window?

If an application window is active and wants another window from the
application to be activated, why wouldn't the user want both windows
on the same workspace?

> - I think we should accept as a fact that some apps will try to activate
> themselves. The WM should detect when it's okay to activate it, and if not it
> should automatically refuse and make it only use the demand attention flag
> (which is what focus stealing prevention does). 

I agree and I think you hit the nail on the head here, Lubos.  Billy
has mentioned the "user gets surprised by window getting pulled to
users desktop" stuff before with relevant bug reports, but those were
all before Metacity 2.10.x--i.e. before focus stealing prevention was
turned on in Metacity.  I'm betting that his real annoyance was with
Metacity unconditionally following _NET_ACTIVE_WINDOW requests but he
placed the blame on what what he saw (i.e. the activation behavior)
without realizing there was something deeper.  Billy: could you verify
(in other words, were the problems your users were experiencing only
occuring when an activation message was sent when no window from the
application was active anymore)?

> With your implementation
> detecting state and acting accordingly (i.e. using demands attention if not
> active) and simply trying to become active will be different because of
> moving between workspaces.

Activation could also be different in other window managers due to
handling of related ancestor/sibling/child windows, show_desktop
state, shading (maybe activating a shaded titlebar has special uses in
another WM?), alternative forms of hiding like shading, existence of
an orthogonal raise option, viewports, and perhaps other UI things
that people haven't yet thought of.  So?

>  Ok, let's try to make this short and simple. What do you suggest happens for:

Note that my suggestions are for what Metacity does, and I think it
would be bad to require other WMs to do the same.

> - the app trying to activate itself (transferring focus between its windows,
> getting a new message or whatever, I hope it doesn't make any difference)

Use all the policy decisions previously listed (includes moving the
window to the current workspace).

> - a taskbar entry is clicked

Depends on whether the taskbar arranges windows in a workspace aware
way[2].  If it does, changing to the workspace where the window is
sounds fine.  Otherwise, the window should be brought to the current
workspace.  All policy decisions not related to the workspace are as
previously listed.

Note that Gnome's taskbar ("Window List" applet) does not list windows
from other workspaces by default.  If the user turns on a preference
to list windows from all workspaces, Gnome's taskbar does not take
workspace into account in any way when arranging the windows.

> - the KUniqueApp case

Use all the policy decisions previously listed.


Cheers,
Elijah

[1] I suspect there are likely do-not-raise-on-click people (namely
those who use the feature for real reasons instead of as a cop-out
workaround for do-not-raise-on-initial-click-of-DND, i.e. those who
truly want an raising to be ortogonal to all other actions) who are
going to take exception to raising being a necessary part of
activation.  They would likely prefer activation to only imply
raise-if-totally-obscured.

[2] If the taskbar has UI that arranges windows in some kind of
workspace aware way then the WM could infer (this is a nested policy
choice here) that the user actually did make a request about all the
unrelated windows on the current desktop and window-to-be-activated's
desktop and thus decide to change to the workspace of the
window-to-be-activated.