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