[xmonad] darcs patch: add configurable X Event handling

[David Roundy]

On Tue, Nov 13, 2007 at 09:58:52AM -0500, Devin Mullins wrote:
> On Mon, Nov 12, 2007 at 01:00:15PM -0800, David Roundy wrote:
> > > I'm sold on the state thing (so long as it can be implemented cleanly),
> > > and you had me at hello with the Message thing, but I haven't budged as
> > > regards the Read/Show requirement.
> > 
> > Fortunately, that last also seems to me to be the least important.  I'd
> > lean towards including it, since it seems like if you introduce a
> > read-failing event-hook, all you've lost is whatever was gained by
> > introducing the Read/Show requirement.  So you don't lose anything by
> > introducing the change (so far as I know).
> 
> Grrr. Events were very easy to do -- just intercept the call to handle.
> Messages come from several places, but (the important ones?) pass
> through broadcastMessage. However, unhandled Events do, too. Double
> trigger seems bad.

True, it would require a bit of restructuring.  Really, there are three
ways messages should originate:  either as an unhandled Event (currently
broadcast), or via sendMessage or broadcastMessage.  The latter two differ
in that sendMessage sends it only to the focussed layout, while
broadcastMessage sends the message to all layouts.

I think we ought to be able to handle this with a minimal amount of
restructuring.  handle itself could trivially be rewritten as a
messageHook.  Then the main event look could simply call broadcastMessage
on every X Event that comes down the pipeline.  broadcastMessage would
first supply the message to the messageHook (or messageHooks), and if it
isn't handled would then supply it to all layouts.  sendMessage (I imagine)
would first give the message to the messageHook and then to the focussed
layout.

To me, subsuming handle in the messageHook framework sounds highly
appealing.  One advantage of this self-modifying hook framework would be
that we ought to be able to eliminate the "dragging" field in XState, which
is really just there to hold an eventHook.

One advantage of *not* making MessageHooks readable is that it'd make it
easier to write a self-removing hook, which would be what we'd want for
something like a dragging hook: we'd want it to just disappear when the
dragging is finished.

I think we've got lots of good ideas here.  Do you think you can code up a
prototype? I have a feeling we could stick most of the code in contrib, so
we could develop together and test it with only minimal changes to core.
We could, for instance, replicate all of XMonad.Main in contrib, so that we
(and other users) could simply call XMonad.Hooks.Main.xmonad instead of
XMonad.Main.xmonad.  I think that'd be an ideal testing ground, and would
allow us to develop this in a leisurely manner without conflicting with
core changes.  Then acceptance into core would consist of a simple copy
of XMonad.Hooks.Main to XMonad.Main and a redefinition of
XMonad.Operations.broadcastMessage.  I think handling sendMessage could be
done subsequently.  We might not even want sendMessage to go to
messageHooks, since in a sense it is a "targeted" message, sent
specifically to the current layout.  In any case, we could wait on
rewriting sendMessage to go throught the messageHooks.

Have you (Devlin) got time to get this going?
-- 
David Roundy
Department of Physics
Oregon State University