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

[Lubos Lunak <l lunak suse cz>]

On Thursday 26 of May 2005 00:48, Luke Schierer wrote:
> 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.

 Oh, I can assure you, there are bugreports for KDE about this too, and I'm 
aware of a couple of things that are still broken in KDE WRT focus stealing 
prevention. That said, since KDE's implementation really pre-dates the spec, 
I've had already enough time to iron out the worst problems.

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

 If that "we" means "Gaim developers", then "we" have nothing to do with this. 
It's the desktops job to decide whether launching app is an user interaction, 
and most users would be probably rather confused it if wasn't considered to 
be an user interaction.

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

 If the application already is active, it seems most logical for the WM to 
automatically activate also any new window from the application, at least I 
cannot think of any good reason why this shouldn't be so. That said, this 
still can be done with mapping a new window with _NET_WM_USER_TIME being set 
to 0, meaning dont-focus (although that at least in KDE's case also means 
setting DEMAND_ATTENTION on it). If there's really need, we may find a new 
way to specify that in some special cases a new window should not get be 
activated and shouldn't also get DEMAND_ATTENTION.

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

 Can you imagine the amount of work if you'd have to tell for every single 
window whether it should be activated? The much simpler logic here is "the 
new window gets focus, because it belongs to the active application".

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

 The way this is written it's the same like #1. Just in case you meant to say 
"window does not get focus", then it's the case above, we could create a new 
hint. This is rather a rare case though.

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

 Indeed. That's the intention of the focus stealing prevention to get in way 
of application that try to get attention just because their author thinks 
they're THE important application or whatever (you'd be surprised what kinds 
of all tricks some apps try just in order to show their unimportant message).

 That said, if getting focus is just a configuration option in Gaim, then you 
could use _NET_ACTIVE_MESSAGE with the source indication field saying it 
comes from a tool that represent direct user action. Granted, in this case 
saying those tools are taskbars, pagers and similar is somewhat imprecise, 
but the logic stays - the option in Gaim is a kind of a direct user action. 
Kopete does have such an option and does it this way.

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

 See my explanation in another mail. DEMANDS_ATTENTION can be set by both WM 
and the app, and is reset by the WM when the window gets activated (since 
then it got attention). The difference is how the states are set and unset. 
Should this be more clearly stated in the spec?

 Metacity's lack of support for the urgency hint is Metacity's problem. That 
said, it currently seems to me all your problems are rather problems of the 
Metacity implementation rather than spec problems (well, KWin's 
implementation in the first year was pretty bad, no wonder the Metacity 
implementation needs some time too). Can you try whether some of your 
problems remains if you try also with KDE?

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