[xmonad] darcs patch: add configurable X Event handling

[David Roundy]

On Mon, Nov 12, 2007 at 02:01:26PM -0500, Devin Mullins wrote:
> 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.

Okay.

> > 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.)

Ah, I hadn't looked at that.  Clever (of sjanssen, I suppose).

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

Yeah, that could be a real advantage.  We ought to be able to have a
mixture of state-preserving and non-state-preserving hooks (with care).

> > 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)?

I think the two would need to go together over restart.

> > 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.

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).

But it'll certainly be easier without state-preservation-across-restart,
which means that even if we wanted Read/Show, it'd be a good idea to
implement the hooks without that feature first.  So we could delay the
debate until there are folks who don't want to reconfigure their xmonad
because they'll lose their eventhook state.
-- 
David Roundy
Department of Physics
Oregon State University