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 Tuesday 26 of July 2005 18:54, Elijah Newren wrote:

> > With what policy?  Our policy is if the request is too old (user has
> > done other stuff since requesting the activation), then set the
> > demands attention hint.
> 
>  That's a good enough policy, isn't it :) ?

Well, I had thought so.  :)

> > We can't figure out what time the request was
> > made with 0 timestamps--they're old clients and we'll break things if
> > we just ignore them, so we follow them.

[Offtopic: Now that I think about it, I think I can fix Billy's
problem by patching gdk_window_focus() to use the most recent user
interaction timestamp whenever 0 is passed.  That'll simplify
gtk_window_present() as well...]

> There are (or can be, at  least) actually two timestamps for one window - the
> application's and the WM's. When KWin gets a request from a window and
> doesn't get a usable timestamp with it, it uses its own timestamp for the
> window (from the last time it detected user interaction with the window, or
> it got last valid timestamp for it, or whatever).

Oh, the "requestor's currently active window" field for
_NET_ACTIVE_WINDOW, right?  I had never understood the reasoning for
that.  So, am I correct in inferring that you use this as a backup in
case a timestamp of 0 is provided, making use of the WM's
last_user_interaction timestamp for that window in this case?  Is
there anything else you use it for?  (I'm having a hard time seeing a
use for it if a nonzero timestamp is provided, but perhaps I'm just
missing something again)

Also, one of my main sticking points in understanding the currently
active window stuff was that (correct me if I'm wrong) apps can't
reliably know whether they have a window which is active since they
only get notified of loss of focus after it happens.  Perhaps "the
requestor's most recently active window" would clarify this?  Except,
that would kind of negate the need for sending None sometimes which
the spec allows...  hmm...

It'd be great to clear up this matter.  I should have asked about it
sooner (I know, I should be punished for my neglect), especially since
I wasn't the only one who didn't understand it--see e.g.
http://bugzilla.gnome.org/show_bug.cgi?id=150668.

> On a somewhat related note, would anybody have a problem with the
> attached patch for the startup notification spec. I've already been using this
> in KDE for quite some time, and I've just recently noticed it's actually not
> explicitly said in the spec. It's used e.g. for the KUniqueApplication case -
> if KControl is running, you launch another one, this allows the already
> existing window act like it's a newly launched window.

I have no objections.


Thanks Lubos,
Elijah