On 7/28/05, Lubos Lunak <[EMAIL PROTECTED]> wrote:
> On Wednesday 27 of July 2005 21:14, Elijah Newren wrote:
> > 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).
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.)
> 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?
> 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...
> > 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). Then, if an app later sets
_NET_WM_DESKTOP, you follow it. Is that right?
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...
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
