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

[Elijah Newren <newren gmail com>]

On 5/25/05, Luke Schierer <lschiere users sf net> wrote:

> yes and no.  We set urgency when we deam the window needs attention.
> this is a subset of possible new windows.  *ideally* then urgency
> would be slightly different, *more* prominent from DEMAND_ATTENTION,
> which happens for all windows.  I'm on thin ice here, as *my*
> understanding of the specs involved is *certainly* suboptional.
> hence I didn't write much of that list, I just copied and pasted it
> from the relevent irc discussions and the follow-up thread in our
> mailing list.

Well, my understanding is quite suboptimal, because I merely attempted
to implement what others wrote and I don't have a full understanding
of the reasons for DEMANDS_ATTENTION and Urgency and all that (I
missed the original discussion).  But my understanding was just that
the former was for the WM, while the latter was for the application. 
I don't see why one should be any more prominent than the other,
though that may just be due to a lack of examples that I can think of.
 
> Warren views, as do I, the new behavior, pop under, to be worse than
> the old behavior, stealing focus.  *ideally* neither would happen.
> But that would require that you be able to create windows at the top
> level without giving them focus.  for some reason, that was deamed to
> "demonstrate a lack of understanding of the specification." or
> perhaps that part was simply "misinformed."  Either way,

I think on-top is bad because it obscures the application the user is
trying to interact with.  Part of the reason for the spec is security
problems (window takes focus and gets users password), but part of it
is also least-interruption-to-user.  If user launches application A,
then uses application B, then A finally appears, A should not get in
the way of working with B.  Instead, there should be some kind of
visible notification that a new window has appeared so the user
doesn't miss it (which I admit, I often do miss it with our current
implementation) but can still work with B until *they* decide to start
working with A.

However, I think we can and should move the window to where there is
the least overlap as possible with the window that has focus, to help
make it so that it will be seen when it appears.

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

I disagree, for reasons stated above (I hate apps that interrupt what
I'm working on; notification that they need attention is fine, but
rudely getting in the way of what I'm doing at the moment is not).

>         * Window stacking and focus policy should be at least somewhat decoupled.

It is, so I don't see why this statement has any relevance.  (yes, I
am one of those who would like a more extreme decoupling than what
exists in Metacity, but that's beside the point)  It may not be
decoupled in the way you like, but if so you should state in which way
the given choice of decoupling is suboptimal, rather than make vague
statements like this.

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

Um, like DEMANDS_ATTENTION?  ;-)


Hope that helps,
Elijah