Re: _NET_ACTIVE_WINDOW, revisited

[Lubos Lunak <l lunak suse cz>]

On Sunday 24 of July 2005 22:46, Elijah Newren wrote:
> On 7/24/05, Billy Biggs <vektor dumbterm net> wrote:
> > Elijah Newren (newren gmail com):
> > > On 7/21/05, Billy Biggs <vektor dumbterm net> wrote:
> >  Lubos' KUniqueApplication example was an
> > interesting one, but I haven't seen any application that does this today
> > (and it could be implemented directly using the desktop switching
> > hints).
>
> *sigh* I'm assuming you're referring to using _NET_WM_DESKTOP +
> _NET_ACTIVE_WINDOW (correct me if I'm wrong) to do such a direct
> implementation.  And no, that would not work--at least not in all
> cases.  What about WMs that support both workspaces and viewports?  If
> the window is in part of the viewport that is off the screen, then
> _NET_WM_DESKTOP doesn't put it on the screen.  And if you are of the
> I-don't-like-workspace-switching-as-part-of-activation crowd, then you
> will probably be of the
> I-don't-like-viewport-scrolling-as-part-of-activation group either.
> That means the app pulled the window to the current desktop, and the
> WM scrolls the viewport somewhere else.  Then there's all kinds of
> complaints because the app meant to pull the window to the currently
> viewed area (workspace + viewport region) but it just didn't happen to
> 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.

> I am becoming really worried that we are collectively messing up in
> the same ways that those before us have.  We saw some of those
> previous mistakes and e.g. made _NET_WM_WINDOW_TYPE so that WMs could
> decide policy instead of apps doing so and thus provide a consistent
> environment.  Yet we're providing all kinds of ways for apps to
> dictate behavior and even encouraging apps to do so (e.g. Billy's
> suggestion that apps could using workspace switching messages + a
> activation message to get windows to the current workspace, Lubos's
> exact same suggestion for gtk+ to do that for all apps that request
> activation in his
> http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00062.html
> email,

 Frankly, it didn't even occur to me somebody would actually like windows to 
change their desktop just as a result of activation. The basic idea behind my 
reasoning is "don't affect the window (more than necessary)". If the window 
is minimized, it has to be unminimized, because otherwise there's simply no 
way to activate it. But moving the window to another workspace is a change 
that's not necessary, that's changing a property of the window that wasn't 
requested to be changed. That's why I also think _NET_ACTIVE_WINDOW should 
primarily only try to affect the activity state of the window and nothing 
else.

> >   My problem is this:  if _NET_ACTIVE_WINDOW can cause windows to switch
> > which desktop they're on, I have to somehow modify my code to only use
> > it when I know the application is currently visible, which is hard.
>
> Activating a window is done so that the user can use it.  One should
> therefore only activate a window if the user wants to use it.  The way
> for a user to decide to use an app is to initiate some action, not for
> the app to divine that the user should use it right now (if an app
> thinks it deserves attention, it should set urgent or
> demands_attention hints). I don't see how whether the application is 
> currently visible changes the user's intent to use the app.  Feel free
> to point out how it should, though--I'm just not currently
> understanding how it could be so.

- It is noticeably simpler for the app just to try to activate its window then 
to detect in which state it is and act accordingly. What if it is active and 
it only wants to activate its other window?
- I think we should accept as a fact that some apps will try to activate 
themselves. The WM should detect when it's okay to activate it, and if not it 
should automatically refuse and make it only use the demand attention flag 
(which is what focus stealing prevention does). 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:
- 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)
- a taskbar entry is clicked
- the KUniqueApp case

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