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]