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

[Lubos Lunak <l lunak suse cz>]

On Wednesday 27 of July 2005 21:14, Elijah Newren wrote:
> On 7/27/05, Elijah Newren <newren gmail com> wrote:
> > > 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.
>
> Actually, can I wait a little longer before making that judgement?
> Looking closer, I'm not so sure I know what it means anymore.  Does it
> mean the WM should ignore the _NET_WM_DESKTOP field on its next map,
> set it to the current workspace, delete that property on the window,
> or something else?

 It should do exactly the same like it does when a new window with 
_NET_STARTUP_ID is mapped (ok, not exactly, since I mapped windows has to 
have _NET_WM_DESKTOP set ). KWin simply applies all values from the startup 
notification to the window, so the desktop from it takes precedence to 
_NET_WM_DESKTOP set on the window (even on initial window map actually).

 From the user's point of view this should like the already existing window is 
a new window resulting from the launch. That means it gets the timestamp from 
the launch and the virtual desktop from it (the startup notification spec 
currently doesn't have more fields that could be applied). Or do you have a 
better idea how to achieve the same? I bet you sometimes reuse existing 
processes and their windows in GNOME too.

> At first, since I was thinking that I should treat it like a launch
> and the default with new windows is to put them on the current
> workspace I thought about doing that.  But what if the window is
> sticky? And what if the app sets a new value for _NET_STARTUP_ID and 
> then wants to also specify a value for _NET_WM_DESKTOP?

 I guess that's up to you (=WM) to decide and it IMHO doesn't really matter. 
But note that the _NET_WM_DESKTOP case doesn't apply here, as nothing happens 
with the window except for _NET_STARTUP_ID being updated. The closest thing 
to this that can happen is that the app updates both the properties, but 
since that cannot be done at the same time you'll see it as two following 
changes.

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