Re: Window History Placement

[Matthias Clasen <maclas gmx de>]

> On Wednesday 29 of January 2003 02:50, Matthias Clasen wrote:
> > In an attempt to get anywhere wrt. to History Placement, I tried to
> > figure out what, if anything needs to be added to the EWMH. Is this
> > agreeable ?
> 
>  The parts about placement policies are fine, but I still fail to see why
> one 
> single placement policy should have some special priviledges hints. If 
> somebody invents yet another placement policy, will it have its extra 
> properties too?

Because the history placement policy has a requirement which the other
policies do not have:
uniquely identify a window in a particular way. By this I mean that the X
window ID is useless,
because it isn't meaningful across server restarts, the PID is completely
inadequate for this purpose and there may well be places where the
WM_NAME+WM_CLASS combination doesn't cut it either, because the name may contain
irrelevant details like dates.

> 
> > +	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).

But storing locations is not really applying a placement policy, it is just
enabling the application of
history placement to the next instance of "this" window. Thus it should be
controlled separately, but
I don't think this is the main point. It would be ok to interpret
USPosition/PPosition in this way, but
we still need a way to explicitly specify the window identity.

> 
> > +	To identify a window without  NET WM SAVE ID for the purpose of
> > +        history placement, the Window Manager may use the combination
> of 
> > +        WM CLASS, WM NAME and WM WINDOW ROLE plus an additional tag to
> > +	differentiate between windows with the same (WM CLASS, WM NAME,
> > +	WM WINDOW ROLE) combination. One possibility to generate the tag is to
> 
> 
>  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?

PID is completely besides the point, since you want to reuse the location of
a previous instance which
ran under a different PID than this instance. You are right that
SM_CLIENT_ID+WM_WINDOW_ROLE
should uniquely identify session member windows, but WM_CLASS+WM_NAME may
fail to uniquely identify windows of non-session-aware clients. And, more
important, there may well be cases where you 
want to identify windows for the purpose of history placement, although they
have different WM_NAMES.
Silly example: a filemanager window having the current path + size of the
directory in WM_NAME. You would probably want _NET_WM_SAVE_ID to omit the
size...

Matthias

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!