[xmonad] darcs patch: add configurable X Event handling

[Devin Mullins]

On Mon, Nov 12, 2007 at 09:48:11AM -0800, David Roundy wrote:
> I suppose it's a bit of a tossup.  I don't see that as the whole point.  To
> me, the whole point would be to allow the definition of hooks that aren't
> workspace-specific, as is the case with layout hooks.

Well, the only reason I am so eager to see it in core, and wrote the
patch, was to avoid the Read/Show requirement. So it's the whole point
for me.

> Also note that you could make a read-failing messageHook, as you did (I
> believe) with your layout modifier, and the users' result would be much
> less annoying than losing state.  And we could also allow storing of state
> without maintaining it across restarts, which would capture most of the
> usefulness of state-storing.

WithUrgencyHook is not read-failing. If it were, that would suck, as
every user would have to suffer losing layout state accross restart. If
it were silently read-failing (e.g. Invisible), I wouldn't know how to
construct an urgency hook after read start, since it's not statically
linked (as of the config/main inversion). Rather, it's a simple subclass
of (Read,Show) that contains a single urgencyHook method.* (Thanks to
sjanssen for that idea.)

Now, I suppose with eventHooks :: [EventHook] you could isolate the read
failure...

> What do you mean? How it'd work or what it'd be used for? The most obvious
> use would be to simultaneously eliminate the unsafePerformIO global
> variable hack from for the urgency hooks, and simultaneously allow the list
> of urgent windows to be maintained on restart (if that's what we want).

The former could be done without state, by prepending to the main IO
action. (On a side note, I wonder if a better signature for these
"main-modifiers" isn't something like
  (XConfig l -> IO (), XConfig l) -> (XConfig l' -> IO (), XConfig l')
which is able to compose.) The latter; hrm... how can we have readable
state without a readable event hook (cleanly)?

> that I haven't yet imagined.  But basically, my expectation would be that
> just as layouts are now used for interesting features that are unrelated to
> the original "layout" feature (e.g. WorkspaceDir, WindowNavigation, your
> urgency layout modifier) I suspect a general event hook will soon be
> expected to do more than a static function can describe.  In fact, I think

Good point.

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.