Re: _NET_ACTIVE_WINDOW, revisited

[Lubos Lunak <l lunak suse cz>]

On Monday 25 of July 2005 20:44, Elijah Newren wrote:
> On 7/25/05, Lubos Lunak <l lunak suse cz> wrote:
> > On Sunday 24 of July 2005 22:46, Elijah Newren wrote:
>
> <snip>
>
> > > think about other policies that it needed to handle.  Sure, someone
> > > might point out that apps could specify _NET_DESKTOP_VIEWPORT as well,
> > > but that would be missing the point.  Why do apps have to do all this
> > > work?  Why are apps specifying policy?  What if new kinds of UI are
> > > introduced later to supplement or replace workspaces and viewports?
> > > Do we have to update all apps to make them specify the right policy at
> > > that point?  And how in the world do we ensure uniformity across apps
> > > so that behavior is consistent?
> >
> >  Certainly not in saying "_NET_ACTIVE_WINDOW message has actually a very
> > vague meaning and the WM is free to do whatever it wants", which you seem
> > to prefer.
>
> Huh?  That doesn't make sense to me.  We don't specify how WMs must
> handle _NET_WM_WINDOW_TYPE_DIALOG windows.  Some WMs don't decorate
> such windows; others do.  Some may feel they should appear in the
> alt-tab list; others don't.  There's a whole list of properties WMs
> are free to associate with this--it conveys a semantic property type,
> not a set of policy rules.  This enables uniformity across apps
> because apps don't specify the policy.  Sure, the behavior of those
> apps are different when under one window manager than another, but
> under a given window manager all such windows from all apps regardless
> of the toolkit they are implemented with behave the same.  That's the
> goal.

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

>
> _NET_ACTIVE_WINDOW is similar.  Different environments want to provide
> different activation policies.  Having it be vague, i.e. only convey a
> semantic action type, is _exactly_ what allows a given window manager
> to provide consistent behavior for all apps regardless of the toolkit
> they were developed with.
>
> <snip>
>
> The idea behind our reasoning was actually very similar.  We treat
> _NET_ACTIVE_WINDOW as a "do what's necessary to activate this window"
> request from the user and we feel it is important that we "don't
> affect more than necessary to get the window activated."  So, how do
...
 Ok, I see we both have good theoretical backing for our reasoning :). So 
let's skip vague theories talk.

> > With your implementation
> > detecting state and acting accordingly (i.e. using demands attention if
> > not active) and simply trying to become active will be different because
> > of moving between workspaces.
>
> >  Ok, let's try to make this short and simple. What do you suggest happens
> > for:
>
> 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.

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

> > - a taskbar entry is clicked
>
> Depends on whether the taskbar arranges windows in a workspace aware
> way[2].  If it does, changing to the workspace where the window is
> sounds fine.  Otherwise, the window should be brought to the current
> workspace.  All policy decisions not related to the workspace are as
> previously listed.
>
> Note that Gnome's taskbar ("Window List" applet) does not list windows
> from other workspaces by default.  If the user turns on a preference
> to list windows from all workspaces, Gnome's taskbar does not take
> workspace into account in any way when arranging the windows.
>
> > - the KUniqueApp case
>
> Use all the policy decisions previously listed.

> [2] If the taskbar has UI that arranges windows in some kind of
> workspace aware way then the WM could infer (this is a nested policy
> choice here) that the user actually did make a request about all the
> unrelated windows on the current desktop and window-to-be-activated's
> desktop and thus decide to change to the workspace of the
> window-to-be-activated.

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