[Xmonad] More user-friendly hook system

[David Roundy]

On Wed, Oct 10, 2007 at 10:22:45PM +0200, Joachim Breitner wrote:
> > Yes, there are a number of different hook functions defined, but they don't
> > require combinators to be useful.  You're proposing an infrastructure for
> > which it's not clear there's a need.  You're proposing an API without a
> > use (yet).
> 
> I think there is quite some use for it: Currently eight modules in
> Contrib seem to use hooks. And I know at least three possible hooks that
> should probably be added to allow more features to implemented in
> contrib modules (initHook, unmanageHook, clientMessageHook[1]). It does
> not feel right to have not a clear interface for adding new hooks, which
> is what stopped me from implementing features needing these hooks. So I
> think there is a need for an API.

Your propose API is only needed if there's a need for users to easily
compose hooks.

> > > I'd also like to stress that I'm proposing an interface for the
> > > Configuration and a possible implementation -- if someone comes up with a
> > > more suitable implementation, even better!
> > 
> > And what I'm saying is that the best way to propose an interface is with
> > actual code for said interface, and the best way to do this is in contrib.
> > If it's worthwhile, it'll stick around, and if it's small and elegant,
> > it'll be moved to main.
> 
> I can understand that you want these things tested in contrib first, and
> I think I'll create something for conrib once 0.4 is out. But then the
> users have to manually plug each existing hook (currently manageHook and
> logHook) into the new system manually, and the hook internals would not
> be hidden from the user, so two goals of my proposal can't be really
> fulfilled without any changes to the core.

So your two goals are:

1) Make it easier to add lots of new hooks into the core.
2) Make it easier to compose contrib functions that define new
   functionality using hooks.

Adding new hooks to the core certainly requires changes to core, but is
already very easy.  The hard part is convincing people that it's a good
idea.  Of course, new hooks for responding to X events that aren't handled
by core could also be added through contrib, via layout modifiers.  If the
new hooks seem useful, they could be added to the core.

The second goal requires no changes to core.

> But maybe this discussion should be postboned till after 0.4, when we
> will have code to talk about.

Yes, waiting for code does make sense.

> [1] Refering to the XEvent ClientMessage, needed for Ewmh compatibility.

What does this do/need to do?
-- 
David Roundy
Department of Physics
Oregon State University