[Scwm-devs] desired semantics question for window configuration

[Scott L. <sl...@gs...>]

I've got a question about what we should be doing with regards to
storing/restoring window state as I'm currently investigating
window-configuration.scm (which I moved to after determining that
it is making undo.scm fail badly on sticky windows).  I decided
undo was the next to get done since it should help me debug the
stuff that's going to move windows all over the place.

The question is just what makes up the "configuration" of a window.
In some sense the configuration of a window only makes limited sense
without the context of where the display is currently located.  This
is particularly the case with sticky windows.  It makes sense that
sticky windows should have their configuration relative to the viewport
(since they are stuck) rather than desktop (currently they are relative
to the viewport which makes all my sticky windows go wandering off
if I (restore-global-window-configuration (global-window-configuration))
which should be a no-op).  But thinking more about this, this could have
strange interaction with user functions which automatically change the
sticky-ness of windows.  I don't think all strange interactions can
be avoided without reference to the full state at the time the window
configuration was recorded, yet it is very useful in most cases to
be able to record most of the state of the window configuration.
Therefore, we need to determine what we will record and then document
that fact so if there are strange interactions they become the user's
fault if they didn't follow what the docs say.

Also, the functions in window-configuration.scm seem to be poorly
named so I'm considering making aliases and deprecating the old
names.  I also think I'll make the basic data type a record since
the list thing is sort of silly (unless there are objections).
I'll make some sort of accessor like things for getting at the 
interesting fields so we won't have to break backward compatibility
if/when we start storing more state.  Changing from the list will break 
code that relies on the specific format of window configuration.
Er... on second thought, I'm not sure this is a good idea since all
of the other functions return lists.  What do you think?  Maybe the
format of this stuff is something to worry about post 1.0?

Here's what I propose.  Basic goal is to get basic position and
state of windows right and forget the rest for now (decorations,
blah, blah, blah...).  If I'm missing something needed to get
the windows back to the correct position in some circumstances,
YELL at me.  Pretty please?

----------------------------------------

window configuration

frame-size
sticky?
iconified?
shaded?
if sticky?
  position of window/icon relative to viewport
else
  position of window/icon relative to desktop
(window/icon is icon if iconified and window otherwise)

-----------------------------------------

The graphical effect won't be quite as cool since I'll need to
iconfiy/deiconify windows at a different time than the animation
but I don't really care too much and I get the impression Greg
doesn't either (although he's free to comment).

Proposed update order is:

iconify/deiconify as required
shade/unshade as required
stick/unstick as required
animate windows as required to move/resize them to the right location

- Scott