[Xmonad] More user-friendly hook system

[Joachim Breitner]

> > I think introducing a clean, simple interface for hooks for the user,
> > and hiding the details in the type system means that just that: you can
> > freely experiment (adding new hooks, changing the way hooks are
> > implemented) without having the user adjust his configuration file. I
> > don't see how that complicates the core.
> 
> If you're right, then people will use your system, when you introduce it to
> contrib.  If one line of code added to their Config.hs is too much to make
> it worthwhile, I doubt it's going to proliferate anyhow.
> 
> > Also note that there is a proliferation of hooks. At first, it was only
> > the definition of key commands. Then came manageHooks. Later logHooks
> > appeared. I'd almost bet that someone will want a initHook that runs once
> > at start up. For propoer gap-STRUT-handling, an unmanageHook would be
> > needed as well. I'd like to be able to add these hooks without breaking
> > existing hooks and extensions, but also without having the user to figure
> > out manually what extensions expose functions for what hooks and how to
> > combine hooks from different extensions.
> 
> 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.

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

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

Thanks,
Joachim


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

-- 
Joachim "nomeata" Breitner
  mail: mail at joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
  JID: joachimbreitner at amessage.de | http://www.joachim-breitner.de/
  Debian Developer: nomeata at debian.org