[Scwm-devs] Re: desired semantics question for window configuration

[Greg B. <ba...@cs...>]

Undo and window configuration definitely has some potentially surprising
effects---the best way to do undo would be to have each action record
its "undo action" rather than saving the entire window configuration
(though that's also useful for, e.g., bookmarking window configurations,
etc.).

In any case, what you write is perfectly reasonable.  I'd not change
from the list-based representation yet just because it may end up being
a bigger rewrite than you're interested in.  Regarding changes of names,
I'd change the names to things that are consistent and well-named and
make the existing names deprecated aliases to the better-named things.
I don't remember how bad the names are, but assuming they're really
awful and inconsistent, this would be a good thing to do---you may want
to run the names you propose by us just as a teddy-bear-test (you learn
as much from it just because you're explaining it to someone/something
else).

Thanks,
Greg


Scott Lenser <sl...@gs...> writes:

> 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