This is a first attempting at a floating layer:
mod-button1: move window
mod-button2: swapMaster
mod-button3: resize window
mod-t: make floating window tiled again
Moving or resizing a window automatically makes it floating.
Known issues:
Hard to manage stacking order. You can promote a window to move it to the top,
(which you can do with mod-button2) but it should be easier than that.
Moving a window by dragging it to a different Xinerama screen does not move it
to that workspace.
Code is ugly.
The use of arrow keys for swapLeft/Right clash with firefox's back
button. Use the more intuitive mod-shift-jk for this. (It's a movement
operation, after all).
This clashes with IncMaster, so we use mod+comma and mod+period for
these (i.e. the keys mod < and mod > , to move windows to and from the
master area).
While we're here, replace the use of the terms 'left' and 'right' for
navigation, in comments and identifiers, with 'up' and 'down' instead.
Hence mod-j == focusDown. Far more intuitive for people (dons) who live
in fullscreen mode and have vim movement wired into their central
nervous system.
Principle of least VI surprise: movement down or up means using j and k.
This fixes a bug whereby deleting a window will first move focus to
that window before deleting it without moving focus back afterwards.
The fix generalises the remove inner function to delete a window from
the stack whether it's in focus or not. If the window is in focus,
behaviour remains as it was.
In order to give a better account of how focus and master interact, and
how each operation affects focus, we reimplement the StackSet type as a
two level nested 'Zipper'. To quote Oleg:
A Zipper is essentially an `updateable' and yet pure functional
cursor into a data structure. Zipper is also a delimited
continuation reified as a data structure.
That is, we use the Zipper as a cursor which encodes the window which is
in focus. Thus our data structure tracks focus correctly by
construction! We then get simple, obvious semantics for e.g. insert, in
terms of how it affects focus/master. Our transient-messes-with-focus
bug evaporates. 'swap' becomes trivial.
By moving focus directly into the stackset, we can toss some QC
properties about focus handling: it is simply impossible now for focus
to go wrong. As a benefit, we get a dozen new QC properties for free,
governing how master and focus operate.
The encoding of focus in the data type also simplifies the focus
handling in Operations: several operations affecting focus are now
simply wrappers over StackSet.
For the full story, please read the StackSet module, and the QC
properties.
Finally, we save ~40 lines with the simplified logic in Operations.hs
For more info, see the blog post on the implementation,
http://cgi.cse.unsw.edu.au/~dons/blog/2007/05/17#xmonad_part1b_zipper
This means other windows are unaffected.
The change from the previous cycling behaviour was felt necessary, since
cycling isn't a terribly useful operation.
Some properties that hold:
focus is unchanged by promotion
promote is idempotent (promoting twice does nothing)
the focused and master window will swap their positions in the stack
Previously 'promote' would move the currently focused window into the
master position in tiled mode. This was *almost* a cycle of the windows,
but not quite (depending on where the focus was, it was in fact a
cycle).
Now we do the obvious generalisation, and just cycle the current window
stack. Simpler to understand, simpler to reason about.
