While haddock may have choked on -XGeneralizedNewtypeDeriving before, this is
no longer the case. Also this doesn't change the results with a recent haddock
(2.9.2)
Without the change, the errors are like:
> [ unrelated error messages ]
> No constructor has all these fields: `numlockMask',
> `terminal', [every other field set]
With the change:
> `numlockMask' is not a record selector
> [ context where numlockMask is named ]
Changes include:
- compatibility with base-4 or 3 (base-2 untested) by using
extensible-exceptions. This adds an additional dependency for users of
ghc<6.10)
- list all dependencies again when -ftesting (change in Cabal-1.8.0.2)
- remove unnecessary imports
- suppress -fwarn-unused-do-bind, with appropriate Cabal-1.8 workaround,
described here:
http://www.haskell.org/pipermail/xmonad/2010-January/009554.html
This is a rather big change. Rather than make spawned processes become
children of init, we handle them in xmonad. As a side effect of this change,
we never need to use waitForProcess in any contrib module -- in fact, doing so
will raise an exception. The main benefit to handling SIGCHLD is that xmonad
can now be started with 'exec', and will correctly clean up after inherited
child processes.
If the user used the mouse to change window focus (moving into or clicking on a
window), this should be handled differently than focus changes due to keyboard
commands. Specifically, it's inappropriate to discard window enter/leave events
while the mouse is moving. This fixes the bug where a fast mouse motion across
multiple windows resulted in the wrong window keeping focus.
It's also helpful information for contrib modules such as UpdatePointer - it's
supposed to move the mouse pointer only in response to keyboard actions, not if
the user was moving the mouse.
This patch:
- moves broadcastMessage and restart from Core to Operations (to avoid
circular imports);
- in Operations introduces sendMessageWithNoRefresh and move
updateLayout outside windows.
- broadcastMessage now uses sendMessageWithNoRefresh to obey to this
rules:
1. if handleMessage returns Nothing no action is taken;
2. if handleMessage returns a Just ml *only* the layout field of the
workspace record will be updated.
The only thing I am not sure about here is at what exact point the
startupHook should get run. I picked a place that seems to make sense:
as late as possible, right before entering the main loop. That way all
the layouts/workspaces/other state are set up and the startupHook can
manipulate them.
