Re: No focus on map hint II.

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-06-03 at 08:43, Lubos Lunak wrote:
> On Friday 30 of May 2003 18:07, Owen Taylor wrote:

[...]

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

In GTK+, there is a concept of the current event being processed.
I think this makes sense for most toolkits, even if they don't
have that concept exposed currently.

If you use the timestamp from that event, if any, or 0 otherwise,
you get a different set of events right:

 A) Spontaneous popups from timeouts or network activity are
    right.

 B) However, if an application, in response to a user action,
    does some work, then pops up a dialog asynchronously,
    it might not get focused.

On consideration, it seems to me that it is easier for
an application program to understand an API call:

 gtk_window_set_activate_on_show (network_dialog, FALSE);

Than a call:
 
 gtk_window_set_activate_timestamp (async_dialog, saved_timestamp);

So, I withdraw my objection to using the timestamp from the last
event.

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

OK, so you are talking about initial map, not updates to the value
on user activity. That wasn't clear to me.

I guess the question is whether you consider an application using 
Xlib to set _NET_WM_USER_TIME on one of it's window to be a reasonable
way of saying "don't focus this window on map". To, me, it isn't.
I couldn't tell a GTK+ programmer to do that with a straight face.
We'd presumably have a:

 gtk_window_set_activate_on_show (window, FALSE);

type API call.

I think in general, we should take the attitude that the toolkit and
the application must cooperate to properly set the hints on a window
for the window manager; how the toolkit and the application
cooperate is outside of the spec. 

The CARDINAL[] idea makes no sense to me except in the context of
a specific application/toolkit interaction, so to me doesn't belong
in the spec.

Regards,
                                                 Owen