Re: Window History Placement
- From: Havoc Pennington <hp redhat com>
- To: Lubos Lunak <l lunak suse cz>
- Cc: wm-spec-list gnome org
- Subject: Re: Window History Placement
- Date: Wed, 29 Jan 2003 10:09:22 -0500
On Wed, Jan 29, 2003 at 10:15:14AM +0100, Lubos Lunak wrote:
> > + If it is set to the empty string, the Window Manager should not store
> > + the location of this window for history placement.
>
> If the window has explicitly set position (UPosition or PPosition), the
> Window Manager should not store the location of this window for history
> placement. (Well, simply because it shouldn't apply any placement policy for
> such window).
My feeling is that ignoring USPosition/PPosition is a WM policy that
the spec should allow. I don't think it's a WM policy that a practical
default window manager for an OS can have, because it breaks
real-world stuff, but if all apps really behaved exactly as they
should, and we covered all the cases we should in the WM spec, then
USPosition/PPosition would theoretically only be required for
--geometry.
So we might say USPosition should be used for --geometry (or
equivalent), and PPosition basically means "here we are working around
the WM"
Anyhow, I'm not sure we have to bring up the USPosition/PPosition can
of worms in the EWMH, at least, it doesn't seem an essential part of
_NET_WM_SAVE_ID.
> To identify a window for the purpose of history placement, the Window Manager
> may use the combination of WM_CLASS, WM_NAME, WM_WINDOW_ROLE and either
> _NET_WM_PID or SM_CLIENT_ID on the client leader window to differentitate
> between windows with the same (WM_CLASS,WM_NAME,WM_WINDOW_ROLE) combination
> (as that's enough for unique identification of any window, unless the app has
> it broken, in which case one more property available for making it broken
> won't help).
>
> Why would any of the above need some _NET_WM_SAVE_ID?
That I can see, _NET_WM_PID isn't useful here, it doesn't come back the same.
_NET_WM_SAVE_ID lets apps:
- explicitly control placement history, which may be pretty different
than SM; for example a valid way to handle SM is to just close all
dialogs on session save, rather than setting the role on them
- lets them disable placement history
- lets them detect whether the WM supports placement history
by checking for support of _NET_WM_SAVE_ID
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]