Re: _NET_ACTIVE_WINDOW, revisited

[Elijah Newren <newren gmail com>]

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:
> > >   Isn't the only application-class where you want this
> > > jump-to-current-desktop behaviour 'gaim' or other apps which have a task
> > > bar item, you click on it, and the gaim window appears on your current
> > > desktop?
> >
> > Personally, no.
> 
>   What's the other example?

It sounds like you're asking for my policy preferences or perhaps for
the Gnome usability team's policy preferences (which don't always
jive...), but that is perhaps better discussed elsewhere.  Yes, it's
reasonable to ask considering that's how the rest of the thread has
gone, I guess, but it seems weird to me that we're spending time on
what policy people like and why and that we're doing that more than on
how to make the spec so that WMs can do their job and apps can work
and be consistent.  And if you'll permit me, I'd like to object to the
question for a secondary reason in that I feel it is leading.  It
could be fixed by asking for examples instead of "the" example, but a
much easier question for me to answer would be "Where don't you want
an application's workspace to change as part of activation?" (for us,
the answer to that question is only
for-pagers-which-have-workspace-aware-UI, while for other WMs it could
be under-no-circumstances-whatsoever)

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

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, and my suggestion for using _NET_CURRENT_DESKTOP +
_NET_ACTIVE_WINDOW to get the don't-change-window's-workspace behavior
wanted by the pager regardless of the WM's policy for
_NET_ACTIVE_WINDOW)

>   I'm sorry, I don't understand your response.  What's the third policy
> I have introduced?

My understanding of everyone's suggested policy (correct me if I'm wrong):

Lubos' policy: don't change any window's workspace as part of activating it

Gnome's policy: change windows' workspaces in order to activate unless the
  request came from a pager-with-workspace-aware-UI

Your suggestion: don't change any window's workspace as part of activating it
  except for requests that come from pager-with-workspace-unaware-UI

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

Cheers,
Elijah