Using Typeables as the only constraint on layout messages is a bit
scary, as a user can send arbitrary values to layoutMsg, whether they
make sense or not: there's basically no type feedback on the values you
supply to layoutMsg.
Folloing Simon Marlow's dynamically extensible exceptions paper, we use
an existential type, and a Message type class, to constrain valid
arguments to layoutMsg to be valid members of Message.
That is, a user writes some data type for messages their layout
algorithm accepts:
data MyLayoutEvent = Zoom
| Explode
| Flaming3DGlassEffect
deriving (Typeable)
and they then add this to the set of valid message types:
instance Message MyLayoutEvent
Done. We also reimplement the dynamic type check while we're here, to
just directly use 'cast', rather than expose a raw fromDynamic/toDyn.
With this, I'm much happier about out dynamically extensible layout
event subsystem.
This also fixes a bug where xmonad was assuming a 24-bit display, and just
using, eg, 0xff0000 as an index into a colormap without querying the X server
to determine the proper pixel value for "red".
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.
I don't think we're going to see any Xinerama support upstream, at least not
anytime soon. It doesn't make sense to ship something with xmonad that isn't
going to work out of the box. So for now Xinerama users should just use this
patch: http://www.jcreigh.com/xmonad/xinerama-dmenu.html
This requires a dmenu that will accept -x and -w. Currently, This means
applying this patch: http://www.jcreigh.com/dmenu/position-options.patch (I'm
trying to see if I can get this into dmenu upstream; haven't heard anything
back yet.)
Colors taken from dwm's config.default.h and hard-coded in Operations instead
of Config because of import cycle.
Windows overlap slightly in the current tiling algorithm and sometimes prevent
the active window from being completely surrounded by a red border.
