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

[Luke Schierer <lschiere users sf net>]

On Wed, May 25, 2005 at 05:42:22PM -0600, Elijah Newren wrote:
> On 5/25/05, Luke Schierer <lschiere users sf net> wrote:
> > On Wed, May 25, 2005 at 04:20:55PM -0600, Elijah Newren wrote:
> > 
> > We are not treating application launch as user interaction.  User
> 
> Your statement is vague.  Do you mean that you are treating
> application launch as though it is not ever due to user interaction,
> or you just aren't necessarily treating it as being due to user
> interaction?  There's a world of difference between the two.  I'll
> assume the latter, since that makes more sense to me (sometimes
> applications are launched due to user interaction, sometimes they
> launched for other reasons).  Note that I didn't assume that
> application launch was user interaction either; I said "a user
> launches" an application, implying that it was caused by user
> interaction.

basically that we had not considered any case of application launch
as user interaction.  Not that this is necessarily correct.  I
certainly had not considered as wide a range of cases here as you
seem to have.

> 
> > > >         * 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.*
> 
> That makes more sense but seems to say the opposite of what was
> written in your bulleted list ("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")

we seem to have different definitions of "legacy applications."  Even
assuming only 1 gtk version is installed, a gtk program is not
necessarily a non-legacy application.  Or rather, it *is*, but it
*should not be.*  At first glance, yes, its nice to try to handle
this all inside gtk, because it means fewer changes, but it really
only works if all the gtk programs are gnome programs.

Looking at gaim which is gtk but not gnome, we now have a user, in
the shape of Warren, who compiled gaim and gnome against the newer
gtk, and all of a sudden gaim windows started getting lost.  To the
user, this appears to be a bug in gaim, just as previously, the new
window stealing focus appeared to be a bug in gaim.

One way to solve this is certainly to keep the changed code in gaim
and simply to fix DEMANDS_ATTENTION.  and indeed, I do think
DEMANDS_ATTENTION should be fixed, as I admit, when used by the WM it
has a place and serves a valuable purpose.

HOWEVER:  what Etan is saying here, is that the use of
DEMANDS_ATTENTION should be something that a gtk application must
specifically activate.  This would put gaim, with no code changes,
firmly in the camp of legacy applications, and from the users'
perspective, no change will have occured.

The benefit here is that application developers who will have varying
degrees of awareness of the metacity focus and stacking change, will
not be blind-sided by an unexpected and inexplicable change in
behavior.  This may seem like an incredibly minor point for so much
verbiage, esp. since in all likely hood if you did make it opt-in, we
would opt-in.

there may be other benefits (hint to any other gaim developer who may
be reading this) that I am not thinking of.  I do not think that there
are any other draw backs not here listed, the main one seems to be
that it increases the number of legacy applications, and notably
causes it to include (at least for existing versions of gaim) gaim
(as I frankly expected) seems to have heavily influenced the creation
of this spec.

>  
> > > 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.
> 
> Yeah, that was my misunderstanding.  With that information, and your
> examples below, I believe what you say makes sense.
> 
> > 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.
> <snip>
> 
> Yes.  And we needed a concrete way of doing that across toolkits and
> applications (i.e. some implementation details about how to achieve
> this), so Lubos came up with _NET_WM_USER_TIME (and related stuff,
> like DEMANDS_ATTENTION) in the spec.  ;-)

Right. and Etan and Ethan found _NET_WM_USER_TIME to be insufficient,
hence "* 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."  I anticipate
that you will respond that this statement is vague.  It does
continue, giving an idea for an alternate method.

> 
> > > > * 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.
> 
> Yes...but I get the feeling you're implying that we're missing
> something in this part of the spec; I feel we have everything covered
> here--is there something you think we are missing in relation to this?

yes, missing the fact that _NET_WM_USER_TIME isn't really sufficient.
It this constitutes a missing piece.


> 
> > 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.
> 
> Alternatively, read up on XSetInputFocus.  It only fails if the
> timestamp is too old (or too new), but since apps can provide whatever
> timestamp they want, it isn't too hard to steal focus because of this.
>  And without fixing X itself, we really can't do anything about it
> other than attempt to detect it (which is made easier since X notifies
> the WM after it happens) and correct for it.  I don't think this woud
> be a problem with apps accidentally doing this, though I always worry
> that a rogue app could attempt to intentionally exploit this.
> 
> > 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.
> 
> Well, you may be right, I don't know.  The smarter guys like Lubos and
> Rob will have to comment here about the intention of
> DEMANDS_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.
> 
> It'd be better if you just told your users that I suck (I would say
> all the metacity developers here but am afraid of doing so, so I'll
> just speak for myself), point them to the libwnck/metacity bug
> report(s), and tell them that they need to harass me.  I had seen the
> bug report for Urgency, but I tend to have no motivation for bug
> reports about things I don't see the use for (I didn't know of any
> applications that used the Urgency hint, no use case or application
> was mentioned in the report, and I didn't care to implement a spec
> just for the sake of being compliant when there are (as you know) lots
> of real bugs that need fixing).  If you just work around our bugs,
> we'll probably never be notified that a bug exists that needs fixing,
> perpetuating the problem for future application writers.
> 

I absolutely understand not implementing something without
understanding a need for it.  We rather came to this
(DEMANDS_ATTENTION) from the *other* side having needed, looked for,
and found urgency before DEMANDS_ATTENTION was written.

luke

> 
> Hope that helps,
> Elijah
>