[Xmonad] darcs patch: simplify StackSet.delete (and 2 more)

[David Roundy]

On Mon, Jun 25, 2007 at 02:54:05PM +1000, Donald Bruce Stewart wrote:
> droundy:
> > Sorry, I forgot to send this earlier.  These are the changes needed to
> > support sticky windows.
> > 
> > David
> > 
> > Sun Jun 24 07:48:54 PDT 2007  David Roundy <droundy at darcs.net>
> >   * simplify StackSet.delete
> > 
> > Sun Jun 24 07:59:31 PDT 2007  David Roundy <droundy at darcs.net>
> >   * make delete work when window is in multiple workspaces.
> > 
> > Sun Jun 24 08:02:08 PDT 2007  David Roundy <droundy at darcs.net>
> >   * fix apparent memory leak when floating windows are deleted.

In retrospect, I think this last one may be broken.  I'm not sure when
floating windows have their RationalRectangle deleted, but perhaps delete
is not the right time.  I'd really rather we didn't store these silly
things...

> David, can you talk about why/what is needed to support sticky windows,
> how the current semantics have to change, and any consequences that
> might result from these changes? Are there some quickcheck properties
> that can establish the stickyness works? 

The current semantics only need to change is: (i) when a window is closed
we need to delete it from all workspaces and (ii) when layout out
workspaces on the screen, we'd like to ensure that each window is handled
just once.  This second change is really optional (and debateable).  It's
not too bad having gaps where sticky windows are located, and has the nice
property that changing focus from one screen to another doesn't change
one's layout.

Neither of these changes affect any of the behavior of core xmonad when
copy is not used, because in core xmonad you can never place a window in
two workspaces at the same time.

I'm not sure what you mean by the stickiness "working".  It just means a
window exists in multiple workspaces.  I guess you might want to check that
after deleting a window it isn't present in the stackset, even if it's
present in multiple workspaces to start out.  The second property involves
code in the X monad which isn't currently quickcheckable.

> More discussion please!

To actually *use* stickiness (rather than just allowing it), you need two
more functions... well only one really, depending how flexible you want to
be.  You need a function to add a window to a second (or third) workspace,
which I call copy, and which behaves almost like shift.  Or you could
forget flexibility and only allow a window to be made 100% sticky, but that
seems less nice.  And you'd also like to have a function to remove a window
from a given workspace without closing it (unless this is its only
incarnation).  I called this kill1.

Basically, stickiness is almost trivial with the design of xmonad.  All you
really need is to ensure that delete gets rid of all copies of a window,
and that change doesn't affect the non-sticky semantics at all.
-- 
David Roundy
Department of Physics
Oregon State University