Re: _NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

Hi,

Sorry, part of my previous proposal & wording were due to me
forgetting entirely about the source indication field that already
exists (I was worried about distinguishing between pager and
application requests for activation, as I'd like to treat them
slightly different in regards to showing desktop, stacking, and
transients)

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

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

Thoughts?