Re: _NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

On 7/27/05, Lubos Lunak <l lunak suse cz> wrote:
> On Monday 25 of July 2005 20:44, Elijah Newren wrote:

<snip>

>  But we do specify some things that must be done, otherwise there would be > no point in having a spec.

<snip>

> > Note that my suggestions are for what Metacity does, and I think it
> > would be bad to require other WMs to do the same.
> 
>  No. We need something that would work everywhere. That's why we have a
> spec.  Kicker's taskbar should work even with Metacity.

Ah, okay, I think I'm following now.  And I agree, Kicker should work
with metacity and gnome-panel with KWin.

> > > - 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).
> 
>  I was expecting some more practical answer, something more along the lines
> of "the app sends _NET_ACTIVE_WINDOW to activate the window". It especially
> interests me for the case below, because frankly I didn't get what you mean.

Oh, right.  In this case, I was thinking that the app should send a
_NET_ACTIVE_WINDOW message to activate the window.  If we need to
differentiate between this case and the KUniqueApp case, then I think
we need to extend the spec.  (But your _NET_STARTUP_ID proposal in
your other email provides this ability, right?)

> > > - a taskbar entry is clicked

I'm not so sure that the spec has sufficient support to get this right
without ill-advised hacks.  This will probably require some
explanation...

Our taskbar, if it shows windows from all workspaces (a preference
that is off by default), in my opinion, should just send a
_NET_ACTIVE_WINDOW message ("do what you need to do to activate me").

Our selector applet (a single icon which, when clicked on, brings up a
menu showing windows from all workspaces with the windows grouped by
workspace) would prefer a "wait!  I have workspace aware UI--please
take that into acount when activating this window" as opposed to a "do
what you need to do to activate me".  In particular, the behavior this
applet has always had is to switch workspaces first, then activate the
given window, which we got by sending a _NET_CURRENT_DESKTOP and a
_NET_ACTIVE_WINDOW message, in that order.  But, that too would
probably be considered busted as far as viewports are concerned as it
doesn't take them into account.   It also kind of sucks because
_NET_CURRENT_DESKTOP results in the default window being focused,
which is a waste given that a different window is about to be focused
(though this doesn't seem to cause any problems).

Also, I don't really like how the selector applet works.  I'd rather
that it were consistent with the taskbar (we try to keep them
consistent in almost all other ways after all).  But, the selector has
had its behavior for a long time and I don't know whether I can
convince the panel maintainers and the usability people to let me
change it (though I haven't tried yet), and I can see a valid reason
behind the difference in behavior even if I don't like it.

Also, this whole thing is complicated even further by the fact that
whoever originally created the taskbar applet (I didn't get involved
in Gnome as a developer until about two years ago) put this stupid
option in there to allow manually specifying whether windows in the
taskbar are moved to the current workspace before activating or
whether the user is moved to where the window is before activating. 
(But the obviously related preferences for viewports aren't provided
and I don't think anyone considered them in the implementation, so I'm
pretty sure our taskbar is busted under WMs that support viewports). 
I'd rather nuke this particular preference and if people wanted it
badly enough stick it in the WM.

> > > - the KUniqueApp case

Send a _NET_ACTIVE_WINDOW message (assuming your _NET_STARTUP_ID
proposal in the other email is sufficient to differentiate between
this and the first case; otherwise, I think we need to extend the
spec).



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

Cheers,
Elijah


[1] If one makes their pager switch the window's workspace and the
other makes their pager switch the workspace then activate the window,
then they're incompatible in behavior.  Sure, both could add
preferences, but that requires users do a lot of configuration to get
a "drop-in" replacement--and many pager authors will be uninterested
in supporting all possible configurations that every one else might
feasibly run with.

[2] The only way to make sure they were correct on all WMs would be to
make sure they remember to specify behavior for things like viewports
too, and hope that no new funky stuff gets added to the spec that
requires further behavior specification