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".
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.
Changes mean:
* gmrun is like the dmenu key, but with shift set.
- , ((modMask .|. shiftMask, xK_F11 ), spawn "gmrun")
+ , ((modMask .|. shiftMask, xK_p ), spawn "gmrun")
If no one actually uses both gmrun and dmenu, we should consider only
using mod-p for this.
* restart is like quit, but with 'ctrl' set:
+ , ((modMask .|. shiftMask, xK_q ), io $ exitWith ExitSuccess)
+ , ((modMask .|. shiftMask .|. controlMask, xK_q ), io restart)
* revert to 'wer' ordering for xinerama screens:
- | (key, sc) <- zip [xK_e, xK_r, xK_t] [1..]
+ | (key, sc) <- zip [xK_w, xK_e, xK_r] [1..]
that's the only binding order that makes sense, since they're meant to
refer to screens 1 2 and 3, hence 'wer' (look at the keyboard to see why)
