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

["Dana Jansens" <danakj orodu net>]

It is very unclear at the moment how the ICCCM InputHint (from the
WM_HINTS property) and WM_TAKE_FOCUS should be interacting with the
EWMH.

The ICCCM provides for focus models for a window:

Input Model     Input Field     WM_TAKE_FOCUS
No Input        False           Absent
Passive         True            Absent
Locally Active  True            Present
Globally Active False           Present

No Input - The application never expects to receive focus.

Passive - The application will get focus but it will not grab it on
its own. Instead it will only get focus if the window manager gives it
to it. The application cannot help determine if it wants the focus or
not at the given time/situation.

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.

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.

On moden systems it seems that applications and toolkits are using the
EWMH to duplicate this kind of behavior, but it is not standardized
through the specification. I'd like to give an example.

Currently (in Ubuntu 6.10), in a default GNOME environment, Metacity
and gnome-panel have a somewhat complex interaction in regards to
giving focus to the panel. The panel is not focus when it is clicked
on generally. However if there is a text field within the panel, and
you click on it, then the panel is given focus.

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.

As I understand it, this behavior is currently provided through the
EWMH as follows: The panel is has its InputHint set to true, telling
the window manager that it can focus it. However, since it's
_NET_WM_TYPE field is set to a DOCK type window, Metacity decides that
it will not pass focus to the window from user actions. Then, when the
input field is clicked on, the panel sends a _NET_ACTIVE_WINDOW
specifying itself. Metacity then acknowledges the request by setting
the focus on the panel.

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

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? When a window sets its window type, which window
types should it not expect to be given focus without requesting it?
Which should it? How does each window type interract with the
InputHint?

Should applications never be calling XSetInputFocus anymore? Should
they always use _NET_ACTIVE_WINDOW instead? This is not said in the
specification, although it is what seems to be done in practice now.
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?

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?

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.