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

[Havoc Pennington <hp redhat com>]

On Thu, 2005-05-26 at 10:40 -0400, Luke Schierer wrote:
> 
> 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.
> 

Yes, for example. But another thing the app doesn't know is which focus
settings the WM is using and what the expected behavior with those
settings should be.

(Of course, my personal view if writing an OS from scratch is that the
whole "separate policy into the WM" thing is sort of wrong, we should
hardcode one focus mode and set of focus behaviors and then apps would
know what to expect, but even metacity hasn't gone that far since it has
to live in a UNIX world. The WM specs certainly continue the ICCCM
tradition of leaving policy to the WM. Mac and Windows don't do this
though, they sanely hardcode a single behavior.)

> > 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.
> > 
...
> Redhat bug 157271 and gnome bug 305499 demonstrate fairly well why I
> think that the pop under policy is the wrong balance to strike

Making the taskbar flash fixes it pretty well though, I think. As those
bugs discuss, sure there are other things we could do, but the taskbar
flash is going to work for most people.

Another thing I'd hardcode if building an OS from scratch: you wouldn't
be able to turn off the taskbar/dock/whatever, so apps would know what
to expect ;-) and if someone decides to turn off the taskbar my view is
that it's their problem - metacity assumes there's a taskbar in its UI
design.

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

In metacity yes, we try to maintain that the window on top is always
focused - at least in click-to-focus mode. This is a deliberate
implementation choice though and is not dictated by the spec.

I think the taskbar flashing is better than raising an unfocused window
that may then obscure the focus window and be confusing.

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

It makes sense. I wouldn't be surprised if one of the specs already
mentions this, but if they don't, we could remind people.

Havoc