[Xmonad] More user-friendly hook system

[Joachim Breitner]

Hi,


Am Mittwoch, den 10.10.2007, 14:04 -0400 schrieb David Roundy:
> > We still would need the record definition in the core, as that is where
> > hooks are called and where new hooks are added. And I think requiring
> > the user to write
> 
> No, the core would remain unchanged, since the core API is unchanged, and
> the record would be defined in Contrib.  Why would you need to define a
> record for your hook type in the core?

Because that’s where hooks are defined, after all. If we’d leave this to
the Config file writer, then he’d still have to adjust the configuration
file for each new hook that the core defines, which is what I want to
avoid.

> 
> > > import XMonadContrib.CombineHooks
> > > 
> > > xmonadHook = combineHooks [ .. ]
> > 
> > instead of just
> > 
> > > xmonadHooks = [ .. ]
> > 
> > whenever they want to use more than one extension, just to safe half a
> > line of code in all the places where hooks are called does not seem to
> > be worth it.
> 
> I'm not convinced that there will be such a proliferation of hooks that
> many users will ever do this.  I suppose that's largely because I don't
> yet use any myself, and haven't seen any reason to define any.
> 
> I'd rather see the core API only complicated when there's a feature that
> can't be added without the complication (as happened with layouts) or when
> it makes things much simpler (or is needed for a reasonable core
> functionality, as with LayoutSelection).
> 
> I'd say that one line and a dozen characters added to the Config file is
> well worth the ability to experiment freely, and allowing us to see and try
> out code.

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.

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.

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!

Greetings,
Joachim

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