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

[Donald Bruce Stewart]

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

How does it interact with Xinerama, if we're viewing multiple workspaces
simultaneously?
  
> > 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.

I think, given there's no discussion with the core devs about these
changes, you should propose 'sticky windows' or something like that, as
a feature request on the bug tracker, so we can consider it. 

It's hard to appraise, and apply, large patches that land on the mailing
list, without first planning the design with the core team --
particularly if they change basic invariants (like no-duplicates in the
stackset). So, usual 'please give us a compelling use case' and
'assurances nothing breaks' :-)

-- Don