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

[Luke Schierer <lschiere users sf net>]

On Thu, May 26, 2005 at 10:44:27AM +0200, Lubos Lunak wrote:
> 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.

Remember I am here responding to comments on a list of things that I
and other gaim developers wrote after finding out about the new pop
under policy in metacity.  it is in reference to that list, not to
our work in gaim itself, that I was using verbs such as "treating."

but either way.  As you rightly point out, we are application
developers, not window manager developers.  You can decide for
yourselves when an application launch constitutes user interaction.
I would likely say "never," but that's a debatable position.

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

No, I really do not see how this is a lot of work.  Perhaps I am
missing something, but how is it different from the current transfer
of focus from, say, the buddy list to a conversation window?

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

Right.  But I've now seen metacity go from bad to worse.  I'd rather
remind you all of things that are already handled correctly lest some
reaction causes things to go worse still.

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

No, I probably wouldn't.  I've found that the set of users who submit
invalid bug reports and the set of users who write other applications are not
disjoint.  Still, yes, perhaps this is as hard as you say, you would
know better than I.

luke