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

[Elijah Newren <newren gmail com>]

On 5/25/05, Luke Schierer <lschiere users sf net> wrote:
> On Wed, May 25, 2005 at 04:20:55PM -0600, Elijah Newren wrote:
> 
> notably because it has been advertized as making metacity's behavior
> the same as kde's,

'Twas the goal.  ;-)

> but kde's has been around longer and doesn't cause
> bug reports

Two things: (1) I think KDE supports DEMANDS_ATTENTION better, (2)
gaim's behavior has changed since KDE implemented this spec--not
directly, but due to the fact that gtk+ has changed.  (gtk+ didn't
have support for _NET_WM_USER_TIME until more recently, meaning that
gaim would be treated as a legacy app.  If you have gaim linked
against an older gtk+, then Metacity will treat it as a legacy app,
which means that it will always place new windows on top)

>, so I *guessed*, an admittedly poor thing to do, that the
> spec was written after kde's implementation.

Well, it was written while the KDE implementation was being worked
out, to make sure that the spec would actually work and that no cases
had been missed in it.  It was pretty close, but it has had a few
changes to correct other problems we've found since then.  So,
although not completely correct, it is a fair approximationto say 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

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.

> > >         * 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")
 
> > 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.  ;-)

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

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


Hope that helps,
Elijah