Re: focus stealing prevention (was Re: _NET_ACTIVE_WINDOW, revisited)

[Elijah Newren <newren gmail com>]

On 7/27/05, Lubos Lunak <l lunak suse cz> wrote:
> On Wednesday 27 of July 2005 18:34, Elijah Newren wrote:

>  I personally think Billy's primary problem is the fact that they use
> _NET_ACTIVE_WINDOW too much. When an application shows a new dialog
> window it shouldn't do _NET_ACTIVE_WINDOW on it just in case or for the fun
> of it. AFAIK all modern toolkits keep the X focus only on the toplevel window
> and maintain their own internal focus, for good reasons. So there should be
> rarely a reason to mess with the X focus.

I'm in agreement with you there.

> > Oh, the "requestor's currently active window" field for
> > _NET_ACTIVE_WINDOW, right?  I had never understood the reasoning for
> > that.
> 
> No. Your problem, if I understand it correctly, is that if you get a request
> that doesn't include a valid user activity timestamp, you don't know what to
> do.

Right.

> To solve this you can keep your own activity timestamp for the window in
> the WM. You can update it from valid timestamps you get from the app, and
> you can also update it if you detect user activity yourself (clicking on the
> titlebar or whatever). If I don't understand your problem correctly then we
> indeed might be talking about different things.

We do that, but we don't know the window the activate request came
from because the "currently active window" is None in addition to the
timestamp being 0.  I guess we could get eclipse (via gtk) to set the
currently active window to something valid, but if we're fixing
something, why don't we fix the timestamp?  ;-)

<snip>
 
>  But now that you ask I'm actually unsure whether it's really needed or if
> just the timestamp could do as well. Hmm ... thinking ... well. It's a bit
> difficult to remember for me. It was quite some time ago, and being the only
> person in the world ;) had some unpleasant consequences like it always being
> me who ran into dead ends from time to time and had to try again differently
> or having nobody to really check the stuff. And, as you probably now know
> yourself, thinking about this can cause serious headache. In fact just

Yep, I totally understand.  :-)

> yesterday I was debugging some problem related to this and I found out I was
> getting wrong results because of expecting some things about the mechanism
> that no longer were true. So it indeed may be the field is just nonsense. And
> from the log messages I cannot quite remember why it found it needed either.
> 
>  Hmm. I think I might know a reason though. Say that you have apps A and B
> running. Activate A, do something in A (that updates its user activity
> timestamp, in the app), activate B, do something in B (again timestamp update
> in the app). Now activate A just by clicking the titlebar, that makes it
> active, but the user activity timestamp in the app doesn't update, only in
> KWin. And now if A wants to activate B's window, KWin wouldn't let it,
> because A has more recent timestamp - only in KWin though, the timestamp in
> the app, and hence in the message, is old. If A adds also its active window
> to the message, KWin will see the request comes from the active window and
> will allow the activation. I guess this might have been the reason why I
> added it.
> 
> Now, there's a rather weird details I might have missed before. Why the hell
> should A decide to activate B without any user activity leading to this? If
> the user clicks in A and that leads to the activation, the timestamp in the
> app will be correct. And the app shouldn't do the activation just for the fun
> of it. So maybe it's really nonsense.

Yeah, cases like this can make your head spin for a while.  :)  This
specific case you dicuss came up during the Gnome implementation
because there is one condition under which it would be valid for an
app to open a window in response to clicking on the window
decorations--namely, if the user clicked on the close button.  But in
this case there's a message from the WM to the client with a timestamp
that initiates the action.  Anyway, I argued like you that, other than
for the user trying to click on the close button of the decorations,
it'd be nonsense for a window to try to activate something or open a
new window and expect it to get focus.  Discussed in
http://bugzilla.gnome.org/show_bug.cgi?id=162980.  (If there ever did
become a reason that the app should open something in response to a
decoration-interaction, I'd argue that a message from the WM to the
client with a timestamp would be needed anyway)


Any other reasons you can think of for keeping the "currently active
window" field of _NET_ACTIVE_WINDOW?

Cheers,
Elijah