[xmonad] darcs patch: add configurable X Event handling

[David Roundy]

On Sun, Nov 11, 2007 at 05:56:39PM -0500, Devin Mullins wrote:
> Question:
>   Should it be eventHooks :: [Event -> X Bool] instead of eventHook :: Event ->
>   X Bool, or should there be a composeEvents function, like ManageHook.composeAll?

I'd actually prefer something like ::

type EventHook = Event -> X (Bool, Maybe EventHook)

This way, we could define an event hook that will remove itself, or modify
itself (or store state).  As it is, this eventHook is rather limited.

then:

eventHook :: EventHook

And we could define one or more composeEvents functions.

I think I'd also prefer for the EventHook to accept a SomeMessage, rather
than an X event.  This would allow us to communicate with EventHooks using
our existing sendMessage function... or allow EventHooks to be written that
intercept messages.  So that we could (if we chose) unify EventHooks with
some of the aspects of ManageHooks simply by sending Messages on
new-window-creation.  So my real preference would be:

type MessageHook = SomeMessage -> X (Bool, Maybe MessageHook)

and then we'd send all Events or Messages to the MessageHook before
processing them with handle or the layout.

At this point, I wonder whether we should follow the layouts more closely
and make the MessageHooks be data rather than functions, so that they can
store state that persists across mod-q.  So we'd have something like:

class Show mh => MessageHandler mh where
      handleMessage :: mh -> SomeMessage -> X (Bool, Maybe mh)
      handleMessage mh m = do b <- staticHandle mh m
                              return (b, Nothing)
      staticHandle :: mh -> SomeMessage -> X Bool
      staticHandle mh m = observeMessage m >> return False
      observeMessage :: mh -> SomeMessage -> X ()
      observeMessage _ _ = return ()

At this point, we've got message handlers that can store state across
restarts (using the same mechanism we use for Layouts), can intercept any
Message, etc.

I defined three methods so folks who don't want changing state, or don't
want to actually intercept messages don't have to worry about how to return
more complicated state correctly.

So your example would be:

data FocusDoesntFollowMouse = FocusDoesntFollowMouse deriving ( Read, Show )
instance MessageHandler FocusDoesntFollowMouse where
    staticHandle _ m | Just (CrossingEvent {}) = return False
                     | otherwise = return False

It's a bit more verbose, but of course, we'd want it in XMC, so the user
wouldn't be much bothered by this.  The user would just specify something
like

  defaultConfig { messageHandler = FocusDoesntFollowMouse }

Of course, we'd want combinators, but those'd be pretty straightforward.

Thoughts?
-- 
David Roundy
Department of Physics
Oregon State University