
On Thu, Oct 18, 2007 at 04:02:49PM +0200, Joachim Breitner wrote:
Hi,
Hello.
0.4 is out, and I'm bringing up my old issue: Hooks.
I quote the docs for the recent UrgencyHook extension:
Change your defaultLayout such that withUrgencyHook is applied along the chain. Mine, for example:
defaultLayout = Layout $ withUrgencyHook $ windowNavigation wnConfig $ LayoutSelection defaultLayouts
It shouldn't hurt to have the "withUrgencyHook $" at the outermost layer, as above, as UrgencyHook is a LayoutModifier, and hence passes on any messages sent to it.
Is this really what we want our users to go through just so that they can add a simple extension? And what do urgency hooks have to do with Layouts? Wouldn't this be much nicer:
I don't see that a list of extensions one place is much harder on our users than a list of extensions some other place.
Add urgencyHook to your xmonadHook list:
xmonadHooks = [ urgencyHook , otherHooksYouAlreadyHave ]
I will, in this post, leave out any discussion on how to implement this. Instead, I'd like to talk about the _user interface_ of adding extensions.
Note that you've immediately restricted the expressive power, by choosing a list (and I presume, choosing that the order of items in the list doesn't matter?). Of course, limiting what we can do can help keep users from shooting themselves in the foot, but it's also not necesarily the best starting point.
Do you think we should make adding extensions easier for the user? How should registering extensions work in the configuration file?
I don't think adding (Foo $) to one part of the file is much harder than adding (Foo,) to another part of the file.
My suggestion is that there should be just one list, xmonadHooks (or xmonadExtensions, to further hide details from the user), where extensions are added. Options are just passed along, so for example:
-- User option for the UrgencyHook extension:
urgencyAction window = do print "Something is urgent"
xmonadHooks = [ urgencyHook urgencyAction , otherHooksYouAlreadyHave ]
Any comments on that?
This definitely could be nice, but I'm not sure that it's sufficiently powerful, and would prefer it to be a contrib API to start out with (as I've said more times that either of us want to count). -- David Roundy Department of Physics Oregon State University