Re: saving window states

[Cristian Tibirna <tibirna kde org>]

On Wednesday, 15 May 2002 09:35, Havoc Pennington wrote:
>
> It's still not going to work though. I've spent a lot of time thinking
> about it and windows just can't be reliably identified as "the same"
> window across withdraw/map cycles.

This might be non-essential, though. I believe the user doesn't understand, 
anyways, the concept of unique X window. she wants some specific actions 
associated with a distinct category: term windows, browser windows, image 
viewer windows. For these, I believe class and perhaps combination of class 
and title should mostly suffice.

You're right that nothing enforces an irc client away from putting a class of 
"Netscape" on its windows. But then, such an app is corrupt anyways.

I dealt with cross session identification of categories in KWM-1. Kwin also 
has state saving facilities. I didn't hear (up to now) complaints from users 
about those.

I find it difficult to enforce a state saving spec on 
windowmanagers/toolkits/applications. There is very little congruence between 
what developer of an app, users of an app and a window manager would consider 
optional/preferable/mandatory. I believe a spec would be useful only as a 
loose suggestion. Some sort of style guide.

E.g. knode (nntp client in KDE) decides it wants to save its position and 
size. I personally hate that it saves its position and doesn't let me to 
disable this. konqueror (and most other KDE apps) save their own size. kwin 
offers posibilities to save most of other states (position, stickiness, 
shading, desktop etc.) but does so optionally and on a per-class/windowtitle 
base. Apart saving of size (which I find mandatory), saving the other states 
usually annoys me.

> I generally agree with your comments, not so much because of user
> choice but because of consistency. If we go that route, my best idea
> for how to do it is with a _NET_WM_SAVED_STATE property containing an
> arbitrary window-manager-provided string. Some WMs could have this
> string be a fixed ID that references a file somewhere, some could
> actually encode the state info in the string. The string would be
> tagged in a standard way with the name of the WM it is intended for.
> The main problem I see here is that you'll lose state for all apps you
> open while under a different window manager from your usual one.
>

This is a good idea, despite the flaw .

-- 
Cristian Tibirna .. tibirna sympatico ca
PhD student .. ctibirna giref ulaval ca .. www.giref.ulaval.ca/~ctibirna
KDE developer .. tibirna kde org .. www.kde.org