Re: How should the ICCCM's InputHint and WM_TAKE_FOCUS interact with the EWMH's _NET_WM_TYPE and _NET_ACTIVE_WINDOW?

[Havoc Pennington <hp redhat com>]

Hi,

To be clear up front, to get this fixed someone will probably need to 
write a patch to the docbook for the EWMH ;-)

Some comments on how I think things should work, though I have not 
thought it through comprehensively:

Dana Jansens wrote:
> Locally Active - The same as passive, but the application will also
> give focus to other windows that it owns of its own free will, without
> any interaction with the window manager, using XSetInputFocus.

My view is that apps calling XSetInputFocus() on managed toplevel 
windows "out of the blue" is probably broken (since the WM has no chance 
to intercept). _NET_ACTIVE_WINDOW is probably almost always correct 
instead. For override redirect, or child windows (widgets), 
XSetInputFocus() is needed obviously.

> Globally Active - The application will not receive focus from the
> window manager. Instead it will determine when it wants focus (from
> WM_TAKE_FOCUS suggestions given by the window manager, or from events
> such as ButtonPress or KeyPress). The application will then acquire
> focus on its own using XSetInputFocus.

Apps that call XSetInputFocus() due to WM_TAKE_FOCUS is OK though, since 
here the WM had a chance to get involved.

> To implement this behavior via the ICCCM standards, you would make the
> gnome-panel follow the "Globally Active" focus model. It's InputHint
> would be set to false, telling Metacity to not give it focus, but it
> would have WM_TAKE_FOCUS, stating that it may take focus on its own in
> the future. Then, when a button is pressed on the text field of the
> panel, it would simply call XSetInputFocus on itself, allowing the
> panel to acquire focus.

Here is some metacity history:
http://bugzilla.gnome.org/show_bug.cgi?id=160470

And links to this wm-spec-list thread:
http://mail.gnome.org/archives/wm-spec-list/2004-October/msg00005.html

I'm quite sure we considered the solution with the globally active 
model, but I don't know why it wasn't used. One problem may have been 
that the panel applets are not the same X client as the panel itself, or 
it may just be that gtk and/or qt make it hard to do it with 
WM_TAKE_FOCUS, or there may have been fundamental reasons.

> It seems that the _NET_WM_TYPE field has now superceded the InputHint,
> but without any suggested symantics for it given in the specification.

metacity also supports all the InputHint stuff, as I'm sure kwin does. 
The DOCK type doesn't affect how focus is given once we decide to focus; 
the DOCK type just affects whether a mouse click tries to focus the window.

In other words, there are two things:
 1) when to focus - which is a WM policy, e.g. some WMs let you choose
   whether the first click focuses, etc. Also remember you can focus
   with keyboard not just mouse, e.g. in metacity ctrl+alt+tab is like
   alt+tab except for panels instead of regular windows
 2) how to focus once we decided the user wanted to focus; this is
   done with InputHint. globally active windows can "veto" the
   focus at this point.

I guess this points to one fundamental problem with trying to handle the 
panel via the globally active model, which is that the panel has no idea 
of the WM's focus policy - in terms of which buttons/keys should focus, 
or whether click to focus is even enabled.

> What should a window manager do when InputHint is set to false, but a
> _NET_ACTIVE_WINDOW is called on it, and it is a NORMAL or DIALOG or
> ... _NET_WM_TYPE?

_NET_ACTIVE_WINDOW does a bit more than just focus (it raises/"presents" 
the window), so my view is that the WM would always do those things, and 
then it would attempt to focus using the InputHint. If the InputHint 
doesn't allow focus, metacity will "fake focus" the window (it will look 
like the window is focused to the user, but really it isn't). If a 
globally active window does not focus itself, then the window would end 
up unfocused.

metacity does this unconditionally without looking at 
_NET_WM_WINDOW_TYPE I believe. The window type is only used to decide 
*whether to attempt* to focus, and if we are going to attempt, the 
InputHint controls *how* we attempt.

> When a window sets its window type, which window
> types should it not expect to be given focus without requesting it?
> Which should it?

The only thing I know of here is that DOCK type needs to activate itself 
if a text input control is selected.

> How does each window type interract with the
> InputHint?

Generally there's no interaction; the window type only interacts with 
whether/when focus will be attempted, not with how focusing is done.

> Should applications never be calling XSetInputFocus anymore?

For managed windows as I mentioned above I'd say _NET_ACTIVE_WINDOW is 
preferred for saying "from a user perspective, the window should be 
activated" but XSetInputFocus() may be used as part of the actual 
implementation of activation, according to the InputHint rules.
The implementation of activation may also include raising, switching 
workspaces, and stuff like that, in addition to focusing.

> If so, what should window managers be expected to do when
> WM_TAKE_FOCUS is present. Should this no longer be used to indicate
> that a window is going to be calling XSetInputFocus sometimes (Locally
> or Globally)? Is the WM_TAKE_FOCUS message expected to _at most_ make
> the client send back a _NET_ACTIVE_WINDOW message?

I don't think there's any InputHint relationship; e.g. afaik metacity 
100% honors the InputHint.

> If applications are never calling XSetInputFocus anymore, we are more
> or less destroying the Locally and Globally Active focus models. Since
> WM_TAKE_FOCUS is used to specify these models, is there any reason to
> honor it at all in a modern desktop?

Back compat if nothing else. But I believe GTK at least uses the two 
active models, I think they may be helpful in avoiding race conditions, 
others would know better.

> None of these interactions between the ICCCM and EWMH are currently
> addressed, leaving them to be implemented in a somewhat random fashion
> from application to application and wm to wm.

Well, to be fair, any app that that isn't totally old and crufty, or 
written by someone with a great love of goofing around with Xlib, will 
be using a toolkit; and the toolkits pretty much sort this out for you.

Assuming kwin is still working the same way as mentioned in the old 
wm-spec-list thread though, I think the main thing to add to the spec is 
that DOCK is expected NOT to be focused on click, and has to 
_NET_ACTIVE_WINDOW itself when an entry box needs to be interacted with.

I don't think InputHint is modified by EMWH since it's an orthogonal 
issue of how to focus, it does not control when to focus.

Havoc