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

[Lubos Lunak <l lunak suse cz>]

On Thursday 28 of July 2005 18:01, Elijah Newren wrote:
> On 7/28/05, Lubos Lunak <l lunak suse cz> wrote:
> You override _NET_WM_DESKTOP if a DESKTOP startup notification message
> is sent, even for initial window map?  So is
> startup-notification/doc/startup-notification.txt wrong?  It says
>
>   DESKTOP
>           the desktop on which the application should appear,
>           counting from 0, as in _NET_WM_DESKTOP. However,
>           this value should never override a _NET_WM_DESKTOP
>           property set on window that's being mapped.
>           This desktop is relative to the screen provided by
>           the SCREEN key.
>
> (I really don't have any clue what's right here as I've avoided as
> much of startup-notification as possible while still getting the
> focus-stealing-prevention done.)

 Is it there? Ok, it is. I don't know why it's there either. But after 
checking I see KWin does as the spec says.

>
> > 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
>
> Couldn't the screen be applied as well?

 The SCREEN value is the (multihead) screen. You cannot apply that, unless 
you'd have some the-WM-can-magically-migrate-apps-between-heads.

>
> > better idea how to achieve the same? I bet you sometimes reuse existing
> > processes and their windows in GNOME too.
>
> Sorry, when I tried to take back the "no objections" I wasn't trying
> to imply that I had some, it's just that I realized that it didn't
> look as obvious as I first thought and I should make sure I understand
> it first.  No, I don't have any better ideas; in fact, I still don't
> understand all of startup-notification.  I'm just trying to make sure
> I understand how to make things work...

 No problem, don't worry.

>
> > > 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.
>
> Okay, so something like: you get a new _NET_STARTUP_ID, you unset
> _NET_WM_DESKTOP, you re-read all relevant startup-notification
> properties (timestamp, screen?, & desktop) and act accordingly (which
> I believe includes setting _NET_WM_DESKTOP to some value, either a
> default like current-screen or the desktop provided in
> startup-notification if there is one).

 Yes. Although the KWin implementation doesn't unset anything, it only 
replaces it with values that are available in the startup notification. Which 
now that I think of it is probably wrong, given the intended purpose.

> Then, if an app later sets 
> _NET_WM_DESKTOP, you follow it.  Is that right?

 Yes, although the idea is that the app just sets _NET_STARTUP_ID and that's 
about it.

>
> Sorry if I'm wasting your time by trying to comment and not really
> groking startup-notification completely.  I should probably just be
> quiet on this issue and get someone else to comment...

 Yeah ... and given the very small value of the number of someone else's to 
comment, we end up again with useless fields in the spec. Better speak up if 
you feel like.

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