Re: Window History Placement

[Lubos Lunak <l lunak suse cz>]

On Wednesday 29 of January 2003 13:17, Matthias Clasen wrote:
[snip]
>
> 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

 Yes, forgot this detail.

> 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

 And you think somebody will make this old non-session-aware client use this 
spec and still not make it session aware? SM_CLIENT_ID identifies the client 
uniquely in the system. And if you expect some up-to-date clients support 
this spec but not use session management, even with RestartNever (which I 
personally doubt but oh well), then I suggest, instead of this very specific 
_NET_WM_SAVE_ID property, we use something more universal, equivalent to 
SM_CLIENT_ID in its purpose.

  I.e. I suggest something like: Every window should have property 
_NET_WM_CLIENT_ID which uniquely identifies the client this window belongs 
to. For example, clients may set this property to the same value like the 
SM_CLIENT_ID property. Every window should be possibly to uniquely identify 
by _NET_WM_CLIENT_ID + WM_WINDOW_ROLE.

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

 That was my mistake, I didn't intend to copy WM_NAME together with the other 
properties. Even WM_CLASS is not really needed, 
WM_WINDOW_ROLE+some_ID_property are supposed to uniquely identify every 
window on the desktop. And since this _NET_WM_SAVE_ID property would require 
some client changes anyway, IMHO it can be simply required instead to use 
this more general solution.

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