Re: _NET_ACTIVE_WINDOW, revisited

[Lubos Lunak <l lunak suse cz>]

On Saturday 30 of July 2005 04:45, Elijah Newren wrote:
> Hi,
>
> > That's why I said "in normal words". The problem is, your description of
> > the functionality doesn't mean anything to me. "A request from
> > workspace-aware pager" ... aha. I don't really know what to do actually
> > do with that, I even don't see the difference between 2 and 3.
> >
> > Also, now that I think of it, "make everything come to the window"
> > actually conflicts with what you want your taskbar to do. Although,
> > perhaps it actually should specify the behaviour. I want KDE's taskbar to
> > always act the same regardless of what you Metacity developers think.
>
> Then we'll have to make the spec spell out a whole lot more than just
> what to do with workspaces (raising, showing desktop, viewports,
> shading, transients/siblings/ancestors, etc.).  ;-)
>
> > It's the taskbar's decision what clicking the taskbar entry will do
>
> I think that's what I was disagreeing with.  The only way to
> completely get that is to specify what _NET_ACTIVE_WINDOW does in
> detail when the request comes from a pager.  So, whenever anyone wants
> to make a slightly different policy, then we have to add a new value
> with a really long description of the exact details that come with it.
>  Further, if anyone comes up with some new cool UI design element that
> we want to use, then our spec is suddenly underspecified and if people
> make conflicting choices then we have to deprecate all the old ones
> and make new ones with more detailed policy requirements.  I think the
> list of policies we'd need to specify is just too long.

 Not really. As far as I can say pretty much everybody (ok, except for 
you ;) ) agrees on one interpretation of what _NET_ACTIVE_WINDOW should do. 
And even then it's just two ways, "go to the window" and "make the window 
come". I don't think there's anything in between. The problem is just 
expressing this in the spec.

> However, I'm guessing that you only really want to specify part of the
> behavior, and even then in a somewhat semantic kind of way (i.e. not
> mentioning workspaces but just worded so that it's clear how to handle
> it and gives the behavior you want).  Something like "pager request to
> activate the window where it is" and "pager request to activate the
> window by bringing it to the user".  That sounds fine to me.
>
> > , we just want to have to use
> > only a single _NET_ACTIVE_WINDOW to avoid some problems like having
> > another window activated if _NET_WM_DESKTOP + _NET_ACTIVE_WINDOW combo is
> > used. For your taskbar-moves-the-window-to-the-current window, your
> > taskbar could actually use 1, so your taskbar would have the "make the
> > window come to the user".
> >
> >  So I actually think having 0 - legacy, 1 - "make window come", 2 - "make
> > everything come to window" should be enough. And perhaps one more, given
> > that you see a difference between your 2 and 3 below.
>
> The 2 and 3 thing was more because I forgot about the source
> indication field and wanted to differentiate between application and
> pager requests...  Anyway, this looks like it works, but I'm kind of
> worried because it means apps should choose between 1 and 2--and I'm
> totally going to ignore what they pick because I think apps should
> only be specifying "do what's necessary to activate me", not
> specifying how the activation takes place.  Is there any chance we use
> the source indication field to handle this extension?  I.e:
>
> 0 - legacy window or pager
> 1 - request from an application to activate the given window
> 2 - legacy pager
> 3 - request from pager to activate the given window by bringing it to the
> user
> 4 - request from pager to activate the given window by bringing the 
> user to it

 I think it'd be better to go with 0 - legacy, 1 - "go to window", 2 - "make 
window come". Source indication is used for more messages than just this one, 
it'd just make it confusing. _NET_ACTIVE_WINDOW message still has some room 
left. Also, your 2 doesn't quite make sense to me, that's just 0 again, and 
if anybody bothers to specify this fields, they can as well already specify a 
better value.

 The WM in the end should probably base its decision on both this field and 
source indication (obey only pagers, use desktop policy for apps).

>
> I think that'd provide what you want (pager hints about how
> window/user move relative to each other), and would also cover what I
> want (can differentiate between apps and the two kinds of pager
> requests).

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