[Xmonad] More user-friendly hook system

[David Roundy]

On Wed, Oct 10, 2007 at 06:51:07PM +0000, Joachim Breitner wrote:
> 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.

Where are the hooks defined? You mean the default hooks that are in
Config.hs? That's easily handled by renaming that function or duplicating
it in Contrib for those who want extra-easy ultimate power.

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

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'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.
-- 
David Roundy
Department of Physics
Oregon State University