Re: No focus on map hint II.

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-05-30 at 06:34, Lubos Lunak wrote:
> On Thursday 15 of May 2003 15:38, Lubos Lunak wrote:
> [snip]
> >
> >  First, the hint that started this all. The only thing I added when
> > compared to the last proposal is that clients should also update the user
> > time in the hint in the visible window, so that the WM is able to detect
> > last user activity in the window if key events don't propagate up to the
> > frame. I also think the name MAP_TIMESTAMP no longer fits, so I suggest
> > _NET_WM_USER_TIME as the name of the property.
> >
> > The patch is attached as user_time.txt . I'd like this one to get in the
> > spec. (I added the note about CARDINAL[] because I use it in code, and it
> > would break code that would strictly request the property to contain only
> > one CARDINAL value - any complaints about that?).
> 
>  Could somebody please say something about this specific part? Qt needs to be 
> patches for this, and since it involves some kind of new API, it needs to get 
> in before Qt-3.2 final, otherwise they probably won't accept it before 3.3.

One reason I haven't responded to this yet is that I don't really have
a good response other than "Ugh". I don't like it, but I don't have
a better suggestion for an overall approach.

First, just to check, is the following a good summary of the problem?

 If the user launches a window via an explicit action, then continues
 interacting with the current focus window, we want to avoid focusing
 the newly launched window. 

 So, for that reason, we want to be able to get:

  A) The timestamp of the last interaction with the active window
  B) The timestamp of the interaction that caused a window to be
     mapped.

The part of the spec dealing with B) seems to me to be suspect; 
consider the case of a window popping up from network activity -
in that case, the _NET_WM_USER_TIME value on both the active
focused window (if in the same app) and the new window would
be the timestamp of the last key/button press event, so it would be
indistinguishable from an explicitely triggered dialog, right?

Wouldn't using the timestamp from the current event, if any, make
more sense?

I'm slightly bothered by the idea that the window manager would et
woken up (to handle the PropertyChangeNotify) on every keypress and
button press. I don't really expect it to be a problem in practice,
however.

(There is a fairly obvious solution to this - put the timestamp
property on a separate child of the toplevel and point to that 
from the toplevel. But that doesn't have the virtue of simplicity)

Can you explain more about the CARDINAL[] hack? I don't really
understand what it buys you... it seems to me that if the application
sets a value, later values set by the toolkit *should* override it.

I think the specification of when to update the property should, in
any case, be more generic than you have specified here; while
ButtonPress/Release and KeyPress are the normal forms of interaction
between a user and an application, they aren't the only possible
forms. Events received from extended input devices via the XInput
extension for example are just as much user interaction.

So, I'd specify it as:
 
 "The last timestamp from user interaction with the window. A client
  that only deals with core events, might, for example, use the
  timestamp of the last KeyPress, ButtonPress, or ButtonRelease
  event. KeyRelease events should not generally be considered to
  be user interaction, because an application may receive KeyRelease
  events from global keybindings."

Regards,
                                                Owen