[Xmonad] Agaginst LayoutModifiers for hooks

[Joachim Breitner]

Hi,


Am Donnerstag, den 18.10.2007, 10:20 -0400 schrieb David Roundy:
> On Thu, Oct 18, 2007 at 04:02:49PM +0200, Joachim Breitner wrote:
> > 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.

Well, the one thing is a list of extensions, so it is clear what I have
to do: List the extensions I want.

The other thing is how I cascade my Layouts, and it is everything but
obvious how an UrgencyHook modifies my layout.


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

I’ve only limited it for the first registering of extensions
functionality, and with a reason: Any power needed above this can be put
in an Extension itself (which would actually reduce code in the core).

The canonical example seems to be matching on window names when managing
a window, where you currently have a function with lots of parameters.
I’d propose to put that functionality in an extension (just like there
is already one for matching XProperties), and let that extension be
configured in whatever way seems to be most suitable. For example:

>
> -- Registering the extensions, naming the options:
> xmonadHooks = [ windowNameExtension nameMatch
>               ,....
>               ]
>
> -- Setting the optins:
> nameMatch :: Window -> String -> String -> X () -- or whatever
> nameMatch w "firefox" _ _ = do ...
>

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

Don’t think it makes a difference that one part of the file might be
explicitly created to register extensions, while the other part was
intended to manage layouts and is just abused to catch messages?

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

Right, and I promised to work on that after the release of 0.4 − that
is, now. But I think you agree that having this in a contrib module can
just be a proof-of-concept and not the real thing, as the goal is to
simplify configuration, and at least for this „proxy module“, the user
would still have to fiddle with the various ways of adding hooks
manually.

I’m also a bit surprised that no one else seems to have an opinion on
this.

Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://www.haskell.org/pipermail/xmonad/attachments/20071018/3d233b22/attachment-0001.bin