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

[Luke Schierer <lschiere users sf net>]

On Thu, May 26, 2005 at 09:32:09AM -0400, Havoc Pennington wrote:
> Hi,
> 
> Not to pile on late, I want to be sure we keep focus on:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=120439
> http://cvs.gnome.org/viewcvs/metacity/doc/how-to-get-focus-right.txt?view=markup
>         
> On Wed, 2005-05-25 at 15:54 -0400, Luke Schierer wrote:
> > * window focus should only be transfered from one window to another by the direct action of the user.
> > 	* The WM does not know when a new window is user initiated or not.
> > 	* The application that requests the new window does know
> 
> What the app doesn't know is that there may have been *more recent*
> focus transfers in other apps or in the WM itself. Basically
> how-to-get-focus-right.txt is more complicated than this.

The application doesn't know if it has focus *right now* or not?
mmm. I think I see what you are saying.  you are envisioning some
application that gets a mouse click on a menu item, and then takes
appreciable time to react to that click in a visible manner.

> 
> The reason we have to put policy in the desktop rather than apps is that
> good policy requires global knowledge of the open windows and
> desktop-wide settings.
> 
> > 	* 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.
> 
> You're assuming a "never focus new windows" policy here. I also take it
> that metacity focusing new windows is why you think metacity was
> historically broken (prior to "focus stealing prevention") and why you
> think Windows is broken. I guess you're entitled to that view, but
> really it is a desktop environment decision and not an app decision.
> The specs are designed to allow the desktop environment to make either
> decision it wants, or to delegate the decision to users.

Yes, I think that always focusing new windows, while perhaps a choice
the spec allows, is necessarily broken behavior.  Really though, I
mentioned windows only to introduce the reality that gaim is not the
only application that has this "huge security risk" of typing in the
wrong window, its common to most instant messangers.

One assumption that I *am* making is nicely highlighted by the
how-to-get-focus-right.txt though, I was not considering anything
other than click to focus, because I have been consistently annoyed
by the inconsistencies discussed in the "Addendum on sloppy and mouse
focus."  Still, I know other gaim developers use those focus models,
so as I was not the sole author of the points list, merely the person
who compiled it from points other developers raised, I do not think
my bias heavily affects other focus modes beyond the compromises that
Addendum already discusses.

> 
> > 	* 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.
> 
> Desktop environments are free to make this decision balancing the merits
> of popping under too many things vs. stealing focus too often. It's a
> desktop policy decision. The spec allows desktops to go either way and
> so blaming the spec is wrong here.

Redhat bug 157271 and gnome bug 305499 demonstrate fairly well why I
think that the pop under policy is the wrong balance to strike, I
think that in an attempt to fix the few cases where an application
can end up with focus unexpectedly, too much effort has been made to
protect the user.  To the extent that this effort is spec mandated,
it belongs on this list, to the extent that its a choice, it
doubtlessly belongs in other forums.  I chose this list because, not
familiar with the gnome lists at all, I was pointed to it as being
the appropriate place. (some of this is in response to other emails
which say that this thread is off topic)

Also, to the extent that 305499 is *fixable* and is, in fact, fixed,
that is, to the extent that is possible to draw the users' attention
to a window they cannot see, then this balance becomes more
reasonable, but I think its still less than ideal.  The transparency
option was an intriguing one though, that would allow for a far more
ideal balance.  But that is *certainly* an implementation question,
not a spec question.

> 
> > * 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.
> 
> These are desktop policy and quality-of-implementation issues, they
> aren't in the spec on purpose.

fair enough.  I disagree some, it seems that the spec should ban
choices that will never be good, but most window managers do a decent
enough job with the existing specs and their own developer's
intuition to guide them.

I'm reading that cvs page you linked to, and I'm still getting the
impression that Z-level and focus are in fact still coupled in
practice, though they are not inherently so by spec.

> 
> > * Applications which currently have focus should be able to hint if a window said application has
> >   created gets focus or not.  It should be able to do so without changing the level at which the window
> >   is created (assuming the hint is followed).
> > 	* 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.
> 
> You can set _NET_WM_USER_TIME to 0 to indicate that the window
> definitely should *not* be focused, if the window is not the result of
> user interaction.
> 
> Otherwise, you need to give a specific scenario where _NET_WM_USER_TIME
> produces a result in conflict with the intended desktop environment
> policy. We can then address that scenario.
> 
> > * 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. 
> 
> This is unfortunately not fixable in X (the window manager can't
> override SetInputFocus, other than by "fighting" - immediately moving
> the focus somewhere else).

So then the spec should say something about not abusing that ability,
no?  Certainly the ICCCM has things to say about how applications
should behave, not just the window manager, couldn't the
freedesktop.org stuff do the same?

luke

> 
> >  Changes to individual applications at a source code
> >   level should not be necessary for this behavior.
> >   * _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
> > 	* 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.
> 
> Urgency is completely trivial to add support for, far more trivial than
> the difficulty of this argument on wm-spec-list, or you guys' previous
> discussions. ;-)
> 
> Applying the patch in 
> http://bugzilla.gnome.org/show_bug.cgi?id=120439
> is trivial too.
> 
> So, someone should just code this up.
> 
> Havoc
> 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>