Re: _NET_ACTIVE_WINDOW, revisited

[Lubos Lunak <l lunak suse cz>]

On Wednesday 27 of July 2005 21:03, Elijah Newren wrote:
> On 7/27/05, Lubos Lunak <l lunak suse cz> wrote:
> > On Monday 25 of July 2005 20:44, Elijah Newren wrote:
> >  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.
...
> >  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?)
...
> > > > - 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).

 Yes, the _NET_STARTUP_ID proposal is sufficient, assuming there actually is a 
startup notification. If you launch the app e.g. from Konsole, there's none, 
yet the app should come forward. The KUniqueApp code checks if it has a valid 
startup notification ID and if the WM supports it, if yes, it relies on the 
WM. In the other case, it has to do it on its own. I guess we might consider 
this to be an unimportant case.

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

 Frankly, I as a user can't imagine virtual desktops being useful the way your 
taskbar works. 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 ;).

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

 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.

 
 And, while we're here, I wonder what, if, others on this list think about 
this.

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