Re: No focus on map hint II.

[Lubos Lunak <l lunak suse cz>]

On Friday 30 of May 2003 18:07, Owen Taylor wrote:
[snip]
>
> 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.

 Yes.

>
>  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?

 Yes, it's indistinguishable, and I really don't see any way how to handle the 
case of non-user triggered dialog in the active app, besides linking with 
-lcrystalball. The best solution I can come up with is that for such 
"automatic" dialogs the app should use _NET_WM_USER_TIME=0 (i.e. don't 
focus). Any better idea?

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

 This suggestion doesn't make any sense to me. Could you be more specific 
about what you mean?

>
> 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)

 I inherited this part from older KDE's implementation. But I don't consider 
it a real problem either.

>
> 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.

 No, it shouldn't override it. If you want to use a specific timestamp for 
some window, e.g. 0 for no-focus, then the toolkit obviously shouldn't 
replace it with what it deems to be right. Using PropModeAppend in toolkit 
then would set the property if it's not set yet, and would be in practice a 
no-op if it is set already. I wanted to avoid extra API for this, but maybe 
I'm just complicating things in general with this.

>
> 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.

 I didn't know there can be other input events besides the core ones. Ok.

>
> 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."

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/