Re: What is the purpose of _NET_WM_USER_TIME?

[Joseph Krahn <joseph krahn gmail com>]

On Mon, Feb 23, 2009 at 3:26 PM, Havoc Pennington <hp pobox com> wrote:
> Hi,
>
> On Sun, Feb 22, 2009 at 2:52 PM, Joseph Krahn <joseph krahn gmail com> 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.