Moving initColor to Operations allows it to be used by extensions.
The Pixel component of the color is the only thing we need, so it's simpler
just to deal with that.
According to the ICCCM, clients should send a synthetic unmap event when they
initiate an unmap. The old code waited for these synthetic unmaps to unmanage
windows. However, certain 'obsolete' clients do not send synthetic unmaps
(notably xpdf's find dialog). These windows entered a zombified state: xmonad
does not manage them, yet they are still mapped and raised on screen.
The new algorithm (derived from wmii):
- track windows that are mapped on screen
- track the number of expected unmap events for each window, increment every
time 'hide' is called on a window that is not mapped.
- decrement the expected unmap counter on each unmap event
- treat an unmap event as genuine (ie. unmap the window) when:
- the event is synthetic (per ICCCM)
- OR there are no expected unmap events for this window
Note that this breaks compatibility with certain programs described as
"obsolete" in the ICCCM (1994). See the command above the UnmapEvent handler
for details.
I found it difficult to track down a problem in the restart code where xmonad was silently not restarting. This will log the error to stderr, which should show up in .xsession-errors
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
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.
