Re: _NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

On 7/28/05, Lubos Lunak <l lunak suse cz> wrote:
> On Wednesday 27 of July 2005 21:03, Elijah Newren wrote:

>  Frankly, I as a user can't imagine virtual desktops being useful the way your
> taskbar works. 

With which preferences set?  (It sounds to me like you wanted
show-windows-from-all-workspaces + restore-to-native-workspace, which
is one of the cases we happened to cover, but maybe you had something
else in mind)

> The real reason why I reported the bug for Metacity was
> actually that it was getting really on my nerves whenever I used Metacity as
> a replacement for momentarily unstable KWin. So I suggest you're careful
> here, in case more people think the same way like I do ;).

It actually seems to be a much nastier issue, with people wanting all
kinds of weird choices.  Here's someone who tried to summarize some of
the different possible modes and part of why people might want certain
ways or another:  http://bugzilla.gnome.org/show_bug.cgi?id=81222#c19.
 Do you have any similar bug(s) in kde bugzilla?  I really don't feel
like I understand all the ways the taskbar is used with the reasons
for why people use it that way (I use virtual desktops constantly but
I personally don't feel any need to have the taskbar show windows from
any other workspace than the current one.  *shrug*)

> > Okay, let me take a stab at seeing if I can state my opinions about
> > what to do about all the above in a way that makes sense.  I think
> > _NET_ACTIVE_WINDOW should be a "do what you need to do to activate
> > me."
> 
>  I think I agree here.
> 
> > I think pagers sometimes want to specify something a little
> > different "e.g. please activate me, but note that I have workspace
> > aware UI".  I'd like to avoid having pagers specifying some
> > activation-variant behavior manually with things like
> > _NET_CURRENT_DESKTOP, _NET_WM_DESKTOP, _NET_WM_MOVERESIZE, etc.,
> > because that prevents Kicker, gnome-panel, and others from being drop
> > in replacements for each other[1] and it would also likely lead to
> > pagers being broken under certain WMs[2].  I think a viable solution
> > would be an activation-type field for _NET_ACTIVE_WINDOW.  This
> > activation-type field may also be useful for differentiating between
> > the window-tries-to-activate-another and KUniqueApplication cases.
> 
>  Yes, I guess that could be a good solution. So another field in
> _NET_ACTIVE_WINDOW, with
> 0 - old apps

and old pagers  ;-)

> 1 - the normal _NET_ACTIVE_WINDOW for apps
> 2 - pagers etc.
> 
>  I'd like to keep 0/1 in order to recognize old pagers etc. Actually given the
> way you want to make _NET_ACTIVE_WINDOW work it might be even more
> useful for you.

Yeah, I like 0 being separate.

>  How would we define the behaviour of 2? I normal words I'd describe it as
> "leave the window as it is if possible", but that's no spec talk :). I.e. I
> think the functionality should be "make everything else come to the window",
> as opposed to yours "make the window come to the user" for 1.

I'm worried that if we define it in terms of behavior then instead of
just having pagers use it we'll have apps start using it just to be
different and causing inconsistencies.

I'd like to have both a 2 and a 3, actually.  If we think of the
wording for 1 as
  1 - "a request from an application to activate the given window"
then the definition for 2 and 3 would be something like the following:
  2 - "a request from a pager which has workspace/viewport-aware UI to
      activate a given window"
  3 - "a request from a pager which does not have workspace/viewport-aware UI
      to activate a given window"
The reason why I'd like a 2 and a 3 for this just goes back to the
rationale we have for _NET_ACTIVE_WINDOW[1] and trying to be able to
determine whether we can infer that the user made a request about all
the other windows on the current workspace and
window-to-be-activated's workspace.

Of course, WMs would be free to treat all three request types the same
way or have different policies for each.  (In particular, I might like
to make 2 and 3 different from 1 in regards to show desktop mode, as
well as having 2 different from 3 in regards to workspace switching)


[1] For a referesher, search for "reasoning was" in this email from
earlier in the thread:
http://mail.gnome.org/archives/wm-spec-list/2005-July/msg00040.html