More flexible new window focus setting would be nice

[Olivier Fourdan]

On Fri, Feb 20, 2009 at 11:37 AM, Jarno Suni <j_suni at yahoo.co.uk> wrote:
> --- On Fri, 2/20/09, Yves-Alexis Perez <corsac at debian.org> wrote:
>> From: Yves-Alexis Perez <corsac at debian.org>
>> > If mouse is hovering some other window than the newly
>> created window
>> > when it is created, the hovered window should be
>> focused according to
>> > focus follows mouse policy.
>>
>> That's the focus stealing prevention. The timestamp of
>> the hovered
>> window would have been updated, so it would keep the focus.
>
> Do you mean it is not updated without moving mouse? Do you mean focus stealing
> prevention has higher precedence than new window focus setting? And new
> window focus setting has higher precedence than focus follows mouse policy?
[...]
>
> Can you override focus stealing prevention in the keybinding command? Or in its
> launcher? As I mentioned earlier, I expect e.g. Firefox to raise in start, if I don't work
> on a window after starting Firefox's launcher, but if I e.g. type in a window after
> starting the launcher, I want Firefox to neither raise nor get focus automatically.

There seems to be some misunderstanding on how focus stealing
prevention works, and I believe a good understanding of the mechanisms
involved is required to have the right expectations, at lest from a
user point of view.

For focus stealing prevention to work, there must be a way to compare
times. When a new window is mapped, should it be focused or not
depends purely on user interactions with other windows.

Focus stealing prevention requires several conditions to be met.

1) The currently focused window must maintain and update a property
called _NET_WM_USER_TIME  [1]. This property is used by the window
manager to know when was the last user explicit interaction with the
focused window.

2) When mapping a new window, there are two cases:

2.a) This is a new application that starts, so that new
window/application has no previous user interaction. In that case,
startup notification is used to get the timestamp, which means that
*both* the launcher and the launchee must comply with startup
notification standard (and also that startup notification is used,
being compliant is not sufficient if the mechanism is not used,
that's what the toggle "Use startup notification" is for in
xfce4-panel launchers. For the menu, this is determined by a specific
.desktop field)

2.b) If the application is already running (e.g. firefox opening a new
window is not a new instance of firefox, same for Terminal or Thunar
for example), then the newly mapped window should have a
_NET_WM_USER_TIME corresponding to the actual event that lead to the
creation of the new window. Failing to set that timestamp correctly
will result in either the window never or always being focused.

3) So if the window manager can get the associated timestamp for the
newly mapped window (either 2.a or 2.b), all it has to do is to
compare the timestamps to decide whether or not the newly mapped
window should be focused.

3.a) If the timestamp of the new window is 0, it means do not focus
(that's the contrary of what 0 as a timestamp usually means, as the
macro CurrentTime or its gdk counterpart GDK_CURRENT_TIME both are 0)

3.b) If the timestamp of the new window is past the one of the last
user action for the currently focused window, then it means that the
new window has been triggered after and therefore the new window
should be focused.

3.c) If the timestamp of the new window is before the one of the last
user action for the currently focused window, then it means that the
user had explicit interactions with the current window after the
launch of the new window occurred, so the new window should not be
focused (that is what focus stealing prevention is all about).

As you see, it's fairly simple, at least from the window manager point
of view, it all comes down to comparing timestamp.

But the whole mechanism involves a lot of involvement from all the parties:

- The launcher should use startup notification *and* set the time
stamp correctly (that was broken up to and including rc1)
- The launchee should be compatible with startup notification
- The currently focused window must maintain and update its user time property
- the window manager must keep track of the latest timestamp of the
currently focused window (that was also broken up to and including rc1
because of the addition of _NET_WM_USER_TIME_WINDOW [2] support in
xfwm4 4.6)

That all chain is actually the weakness of focus stealing prevention,
because if any of the components do not play by the rule, it breaks.

Cheers,
Olivier.

[1] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2552314
[2] http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2552388