What is the purpose of _NET_WM_USER_TIME?

[Joseph Krahn]

The wm-spec does not give a very good rationale for the USER_TIME
property. It is supposed to be for prioritizing newly mapped windows,
but that doesn't justify updating the timestamp on every input event.
Some of the overhead is avoided with _NET_WM_USER_TIME_WINDOW, but it
still means sending an XChangeProperty for every key-stroke. Does
updating the time for every event really server a useful purpose?

Joe Krahn
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Joseph Krahn]

On Sun, Feb 22, 2009 at 11:04 AM, Havoc Pennington
<havoc.pennington@...> wrote:
> Quickly googling, here's a random old mail that explains it:
> http://mail.gnome.org/archives/desktop-devel-list/2004-August/msg00158.html
>
> The purpose is to "do what people mean" when deciding whether to focus
> new windows.
>
> Havoc
>

I understand the idea of not stealing focus from an active window, but
I don't see why asking every application to update a timestamp for
every input event is a good approach. It seems functional, but
quick-and-dirty.

Is there a purpose to keeping the timestamp value for all windows, or
is it only used to check the last input on the currently focused
window? It makes a difference, because it seems to me that we just
need to know about the last input event, and not a timestamp for every
window. If tracking input events are important, can't the window
manager monitor all input events on all windows, and keep track of the
last one? This would have a similar overhead, and put the work load on
the window manager, which IMHO makes more sense than mandating
timestamp tracking by all client windows.

Or, there could be a WM_PROTOCOL message that asks the active window
"when was your last input event?", so the extra message overhead is
small.

I compared a simple xterm versus gnome-terminal while holding the
backspace key. The CPU time for xterm and X summed to about 1%. The
same thing for gnome-terminal gave a total of 4% CPU for the terminal
and X. I don't know how much of that is due to XChangeProperty and the
resulting notify events, but 4% CPU for a terminal+X to do essentially
nothing is a lot.

Also, the timestamp doesn't prevent mis-entering input into a newly
popped-up window. A few times, I was reading what I typed, then went
to press enter, only to see it get eaten by some unknown pop-up,
leaving me wondering what I just said OK to. There should probably be
a short delay before accepting input on any new pop-up, whenever the
current window accepts input.

Joe Krahn
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Joseph Krahn]

On Mon, Feb 23, 2009 at 3:26 PM, Havoc Pennington <hp@...> wrote:

> Hi,
>
> On Sun, Feb 22, 2009 at 2:52 PM, Joseph Krahn <joseph.krahn@...> wrote:
>> Is there a purpose to keeping the timestamp value for all windows, or
>> is it only used to check the last input on the currently focused
>> window?
>
> Well, only the currently focused window will get events ... key events
> anyway. And a button event on unfocused window would generally (in
> sane configurations anyway) immediately focus the window. It's not
> like button and key events are arriving in mass quantities; they are
> rate-limited by a person doing the typing and clicking, and generally
> only going to one window at a time since the person can only focus or
> point at one window at a time.
>
> More importantly there's just not a performance issue here, the
> property as specified is working fine performance-wise.

I agree that the performance argument is weak, except that there is a
sufficient rationale to implement the USER_TIME_WINDOW to avoid
sending PropertyNotify events to paused processes. However, I am
assuming that the last user-input is the only thing needed to avoid
focus stealing. In that case, why not have a single global
USER_TIME_WINDOW, where clients can set two values, the window and the
event timestamp. Having the last input event for any window in one
place could be useful, depending on whether USER_TIME for unfocused
windows serves any purpose. That would be a fairly simple change,
especially since many programs have not yet switched to the
USER_TIME_WINDOW.

>
>> window. If tracking input events are important, can't the window
>> manager monitor all input events on all windows, and keep track of the
>> last one?
>
> There's no way for the WM to "snoop" events intended for another
> client; it can grab keys and buttons, but that has other side effects.
You can watch any event for any window, excluding KeyPress events.
But, you can still watch KeyRelease events. Just use the 'xev' utility
with the -id option pointing to any window. If a client does grab
keys, you won't see them (for example xterm running in secure-keyboard
mode), but it is good to check for grabbed input before mapping a
window that will need that input to proceed.

>> Also, the timestamp doesn't prevent mis-entering input into a newly
>> popped-up window. A few times, I was reading what I typed, then went
>> to press enter, only to see it get eaten by some unknown pop-up,
>> leaving me wondering what I just said OK to.
>
>That sounds like it's just a bug in some app or some WM or both.
My point is that not having user input for 30 seconds doesn't mean it
is OK to take the focus, because a user may be just about to begin
entering more input. It may be good to have a 1 second delay between
mapping the window and giving it input focus. But, that is a separate
issue from USER_TIME tracking.
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Joseph Krahn]

On Tue, Feb 24, 2009 at 11:38 AM, Joseph Krahn <joseph.krahn@...> wrote:
...
>> There's no way for the WM to "snoop" events intended for another
>> client; it can grab keys and buttons, but that has other side effects.
> You can watch any event for any window, excluding KeyPress events.
> But, you can still watch KeyRelease events. Just use the 'xev' utility
> with the -id option pointing to any window. If a client does grab
> keys, you won't see them (for example xterm running in secure-keyboard
> mode), but it is good to check for grabbed input before mapping a
> window that will need that input to proceed.
I just did some testing with the X.org server. You cannot monitor
button press or release events for client windows, event though the
Xlib documentation only disallows button press events. So, the WM
would not be able to monitor client pointer events, at least for the
current X.org server, without utilizing an extension to access events.

Joe Krahn
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Joseph Krahn]

Overall, the current USER_TIME method is not really problematic.
However, a Window Manager specification defines methods to interact
with the Window Manager, and it seems a bit inappropriate to require
clients to actively maintain data for the WM. I just think there
should be a better design for the long term. Part of the problem is
that X11 was designed around the idea that the WM manages windows, and
doesn't have a good interface for the WM to handle input focus. Maybe
we need a standard X extension that gives more focus control to the
WM, and eventually make it a required extension, or make it a standard
part of X.

For now, I still think there could be a better approach. I though that
the WM could always monitor input events for the focus window, but the
X.org server apparently does not allow access to ButtonRelease events
outside of the focus window.

The original USER_TIME was modified to support a USER_TIME_WINDOW to
avoid waking up processes that monitor PropertyNotify events. Instead
of also requiring every client to create a USER_TIME_WINDOW, I think
it would be more efficient to use a common USER_TIME_WINDOW, which is
maintained by clients to hold both the Window ID and the event time of
the last user-input event. But, that depends if USER_TIME's only
purpose is to find the last input-event to avoid focus stealing.

Joe Krahn
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list

[Dana Jansens-2]

2009/2/25 Joseph Krahn <joseph.krahn@...>

>
> Overall, the current USER_TIME method is not really problematic.
> However, a Window Manager specification defines methods to interact
> with the Window Manager, and it seems a bit inappropriate to require
> clients to actively maintain data for the WM. I just think there
> should be a better design for the long term. Part of the problem is
> that X11 was designed around the idea that the WM manages windows, and
> doesn't have a good interface for the WM to handle input focus. Maybe
> we need a standard X extension that gives more focus control to the
> WM, and eventually make it a required extension, or make it a standard
> part of X.
>
> For now, I still think there could be a better approach. I though that
> the WM could always monitor input events for the focus window, but the
> X.org server apparently does not allow access to ButtonRelease events
> outside of the focus window.
>
> The original USER_TIME was modified to support a USER_TIME_WINDOW to
> avoid waking up processes that monitor PropertyNotify events. Instead
> of also requiring every client to create a USER_TIME_WINDOW, I think
> it would be more efficient to use a common USER_TIME_WINDOW, which is
> maintained by clients to hold both the Window ID and the event time of
> the last user-input event. But, that depends if USER_TIME's only
> purpose is to find the last input-event to avoid focus stealing.

If there was a desire to change the design of the USER_TIME business,
perhaps it would make more sense to have clients send a ClientMessage
to a window owned by the WM.  This would save the WM a round trip to
the server to get the updated timestamp.

The current description of USER_TIME_WINDOW is not clear about details
of how they are used, such as if every window must point to a unique
USER_TIME_WINDOW.  The intention seems to be that, but it is very open
ended right now, in terms of supporting all the possible
implementations.

Dana
_______________________________________________
wm-spec-list mailing list
wm-spec-list@...
http://mail.gnome.org/mailman/listinfo/wm-spec-list