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

[Havoc Pennington <hp redhat com>]

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

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

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

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

>  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