Re: _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS & urgency

[Luke Schierer <lschiere users sf net>]

On Wed, May 25, 2005 at 04:20:55PM -0600, Elijah Newren wrote:
> On 5/25/05, Luke Schierer <lschiere users sf net> wrote:
>  
> > Hopefully you all will find some of our points/ideas/statements
> > useful, and will come up with something better than either the
> > existing behavior or the new, arguably worse behavior (short of
> > rewriting all existing legacy X applications that might create a
> > window).
> 
> I don't see why you insist that a not-fully-baked implementation
> (which is probably my fault) is indicative that the specification is
> wrong.

notably because it has been advertized as making metacity's behavior
the same as kde's, but kde's has been around longer and doesn't cause
bug reports, so I *guessed*, an admittedly poor thing to do, that the
spec was written after kde's implementation.

> 
> Anyway, let me address some of your points.  (Note that gmail sucks
> with manually spaced tables/lists, so this may not come out very well)
> 
> > * window focus should only be transfered from one window to another by the direct action of the user.
> 
> Basically correct, but too vague to be useful.  What if a user
> launches an application, then interacts with another application while
> waiting for the first application to appear?  You totally miss that
> case.

We are not treating application launch as user interaction.  User
interaction basically means a mouse click in that application, or
another focus transfer type action (such as alt tab).

> 
> >         * The WM does not know when a new window is user initiated or not.
> >         * The application that requests the new window does know
> 
> Yes, and unfortunately getting that information to the WM is a royal
> pain in the rear, as it involves so many libraries and special cases,
> and even apps
> 
> >         * In the case of new application launch, this yields a useful result: you can start several things
> >           in the background (or on login) and not have your focus jerked around as they start.
> 
> Yes.
> 
> >         * While it is acceptable to design a specification by which an application which does not currently
> >           have focus can request it either by creation of a new window, or for an existing window, such
> >           a specification should be an opt-in policy.  quoting Etan:
> >                   "If, however, people feel that there should be a way for an application to request focus on
> >                   mapping that's fine. Such a specification should be written such that it is an opt-in concept,
> >                   not an opt-out one (or one that requires all applications to follow for it to work). For
> >                   example, given our experience with metacity (and the focus stealing prevention spec) the fact
> >                   that gaim does not do anything to accomodate the spec used to cause all of our windows to be
> >                   on top and focused, and now causes all our windows to be popped up underneath other windows.
> >                   This is really an unacceptable way to design a new specification, especially when dealing with
> >                   something as old as X and which has legacy applications which one wants to continue to have act
> >                   correctly. If the purpose of this spec is to only make windows that really want focus on map
> >                   to get it than require that *those applications* set the property to some agreed upon value or
> >                   set of values, and that anything which does not is going to be treated in a wm consistent and
> >                   non-annoying fashion (i.e. not given focus on map, but also not hidden and therefore requiring
> >                   further specification to function usefully)."
> 
> You want to have every application decide whether it gets focus when
> it's mapped?!?!?  That would result in a totally inconsistent

not quite. I want that *only in the case where the application
already has focus.*

> experience, with half the apps choosing one way and the other half
> choosing the other way, and both sides being wrong some of the time. 

perhaps.  but we basically have two cases here.  1)gnome apps 2)all
other (gaim falls in #2).  your gnome apps would all be consistently
right or wrong based on your HIG.  your other apps would be
inconsistent, but then, they already are inconsistent.

> Applications don't have a global awareness of what has occurred, so
> how could it correctly make the decision about whether it gets focus

here is where it is absolutely critical that you realize I intended
them to determine focus only where they already had it.  Perhaps I
worded that badly, if so I appologize and will attempt to correct it.

> when it is mapped?  Applications should instruct the WM about whether
> new windows were launched by user interaction and when, but the choice
> should be up to the WM.  That's the only way to get consistent,
> predictable, usable behavior.

that's not incompatable with what I wrote.  basically, as I
understand it, the window manager always has the final say if a
window gets focus or not.  I'm suggesting it should proactively defer
to the application that currently has focus.

example1: gaim has focus, you double click the buddy list, a new
window is created.  the new window get s focus, because gaim tells
the window manager it should be.

example 2: gaim has focus, a new message comes in.  gaim's
conversation placement policy (which is a preference) says this
window gets focus.  window manager defers.

example 3: gaim does not have focus, a new message comes in. gaim's
conversation placement policy says this should get focus, however,
because gaim does not have focus, the WM does not give the new window
focus, but marks it DEMANDS_ATTENTION (or some such).

> 
> Granted, steps do need to be taken to handle legacy apps as good as
> possible.  But it's a crapshot left up to the window manager on how to
> deal with them, since it's impossible to get things right for them in
> all cases.
> 
> > * new windows should be created at the top level unless specifically requested otherwise by the starting
> >   application.  Placement should reflect some overall policy of the WM, preferably a policy that the
> >   user understands and can predict.  Remembering previous placement is a reasonable, but not required,
> >   part of said policy.
> >         * Window stacking and focus policy should be at least somewhat decoupled.
> >         * It is acceptable for a window manager's overall focus policy to include some concept of absolute
> >           Z-level and restrict an application to a single Z-level.  Such a policy, however, should include
> >           some method to notify the user that a new window has been created.
> 
> I responded to this in the other email.
> 
> > * Applications which currently have focus should be able to hint if a window said application has
> >   created gets focus or not.
> 
> Agreed; that's what the spec does.

right, but if you couple this with my reply above, and the
DEMANDS_ATTENTION stuff you *have* implemented, then you end up with
a whole that is more usable than if you only have some of the pieces.

> 
> >   It should be able to do so without changing the level at which the window
> >   is created (assuming the hint is followed).
> 
> Disagreed; as stated in my other email, I don't think applications
> should be able to obscure what I'm working on--that's not a valid way
> of notifying me that there's a new window to interact with.
> 
> >         * While it may be valuable to specify or further specify how this should be done, _NET_WM_USER_TIME
> >         in it's current overloaded state does not seem to us to be a viable solution for this. We would
> >         suggest something like a _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS property.
> 
> "The Gnome implementation isn't what we want; it obviously isn't
> buggy, therefore the spec is bad and something else should replace it"
> 
> I'm responsible for a large part of the Gnome implementation.  It's
> buggy, and it's mostly my fault.  But it ISN'T a reflection on the
> spec.  ;-)
> 
> > * Applications which do not have focus should not be able to pull focus from another application in a
> >   way that the user cannot disable or modify.  Changes to individual applications at a source code
> >   level should not be necessary for this behavior.
> 
> Yes, and the spec mostly handles this.  Unfortunately, it is
> impossible to achieve 100% because of an inherent design problem in X:
> X allows applications to set the focus and doesn't consult the window
> manager whether such an action should be allowed.  The WM can attempt
> to detect and correct such an action, but cannot prevent it.

interesting, that is not my understanding of how X works.  However, I
am admittedly not fully clued with the specs and such.  I'm going to
ask Etan and Ethan (two other gaim developers who have far more spec
clue than I) about this one.

> 
> >   * _NET_WM_STATE_DEMANDS_ATTENTION may have merit here if used to indicate that a window which requests
> >     focus was not given in so as to comply with the WM's policies on focus.
> > * Window managers and and applications should  both support both the ICCCM and fd.o specs
> 
> No reason to disagree...
> 
> >         * That being said, ICCCM has been a specification since 1993, and (for example) gnome should be
> >           supporting urgency before they get too upset about us not supporting
> >           _NET_WM_STATE_DEMANDS_ATTENTION.  Further, we undertake to implement support for this after
> >           Gnome supports urgency.
> 
> You shouldn't need to do anything to support DEMANDS_ATTENTION. 
> Nothing.  You may need to do something to support _NET_WM_USER_TIME
> (though I don't know of any off the top of my head).  Yes, we need to
> support Urgency, but as I said elsewhere, Urgency support won't help
> you with this problem at all.  What you need is for us to get decent
> support for DEMANDS_ATTENTION.

In our reading of the spec, and in searching the bugzilla and mailing
list archives, we came to the conclusion and impression that
DEMANDS_ATTENTION was designed to be set by *either* the WM or the
app, not *only* the WM.  If it is in fact *only* the WM, then we have
no disagreement here (except perhaps with the clarity of the spec).
If however, it is truly meant such that an application might set it,
then it is a de facto replacement of the ICCCM urgency hint, and as
such objectionable, as even if we came to agreement on every other
point, lacking a gnome side implentation of urgency, we would still
be stuck implementing DEMANDS_ATTENTION ourselves to duplicate the
current urgency functionality, as gnome has no *other* way for us to
tell the user we want attention.

example:  we set urgency on *existing* windows when, based on the
preferences, we deem a window to need attention.  this is what
urgency is designed to do, it does not simply deal with new windows.
with GNOME's current api, we would have to set both urgency (for
other window managers) and DEMANDS_ATTENTION (for gnome), to achieve
the same result.

luke

> 
> 
> Hope that helps,
> Elijah
>