focus stealing prevention (was Re: _NET_ACTIVE_WINDOW, revisited)

[Lubos Lunak <l lunak suse cz>]

On Tuesday 26 of July 2005 18:54, Elijah Newren wrote:
> On 7/26/05, Billy Biggs <vektor dumbterm net> wrote:
> > Elijah Newren (newren gmail com):
...
> >   I think the WM should map _NET_ACTIVE_WINDOW requests to demands
> > attention if they conflict with the policy.
>
> 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 :) ?

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

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

> > I believe kwin implements this well, so this suggests that there is a
> > reasonable middle ground.
>
> Really?  Well, sounds like Lubos is ahead of me yet again.  So,
> somehow Lubos figured out a trick to workaround the problem.  Thinking
> about this for a while, I guess we could ignore such activation
> requests if the currently active window does not belong to the same
> application/group as the window to be activated.  Wouldn't be perfect,
> but might work well enough.  It'd break old taskbars but that sounds
> acceptable (I think it'd be rare for users to use the latest Metacity
> with really old taskbars).  It might also break some accessibility
> stuff like GOK, which probably wouldn't be acceptable right now--I'd
> have to look into it.
>
> I'm guessing this is bugzilla (either Gnome or eclipse) material now
> instead of continuing on wm-spec.  Though I'd love to hear any sage
> advice that Lubos might have.  ;-)

 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.

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

--- startup-notification-0.1.txt.sav	2005-07-27 17:11:43.000000000 +0200
+++ startup-notification-0.1.txt	2005-07-27 17:18:31.000000000 +0200
@@ -352,6 +352,10 @@ _NET_STARTUP_ID, UTF8_STRING
   The ID used for the startup sequence for the window. If set 
   on a group leader window, applies to all application windows
   in that group that do not set their own _NET_STARTUP_ID.
+  
+  If a new value for the property is set, the window manager
+  should update the window's status accordingly (update its virtual
+  desktop, etc.).
 
 
 Launchee failures
@@ -420,3 +424,5 @@ Changes since 0.1:
 
 - TIMESTAMP field is obsoleted by including the timestamp directly in the ID.
 - data from "change:" messages should be used even if they precede the matching "new:" message
+- Explicitly mention that updating the _NET_STARTUP_ID property on a window should trigger
+  window manager's actions for the new startup notification again.