[Xmonad] Constrained dynamically extensible layout events: a patch

Donald Bruce Stewart dons at cse.unsw.edu.au
Fri May 4 10:20:07 EDT 2007


droundy:
> On Fri, May 04, 2007 at 06:07:52PM +1000, Donald Bruce Stewart wrote:
> > dons:
> > > David, Spencer et al, are there any problems with restricting layoutMsg
> > > arguments to being members of the (open) Message class? I'd (strongly)
> > > prefer this over just Dynamic, since it restores most of the static
> > > checking we'd need. 
> > 
> > Oh, I forgot an example. This is why Dynamic-only is scary:
> > 
> >         , ((modMask,               xK_h     ), layoutMsg "hey Joe!")
> >         , ((modMask,               xK_l     ), layoutMsg Expand)
> > 
> > is well typed. Under the new system, it becomes a static error:
> > 
> >     Config.hs:157:43:
> >         No instance for (Message [Char])
> >               arising from use of `sendMessage' at Config.hs:157:43-65
> 
> I personally like the ability to send unaccepted messages.  It can't pose a

You can still send unaccepted messages, but you can't accidentally send
a non-message type anymore.

> problem on the receiving end, since every layout has to be able to handle
> messages it knows nothing about.  So the only danger is foolish users who

Right.

> send messages that have no effect, but that really seems harmless to me.  I
> guess getting better error checking is nice, but it seems like you're
> talking about error checking for something that really isn't likely to be a
> problem.

Well, its pretty light, and more static checking is always good, in my view.
This guides the user a bit more towards valid code. Is there any downside?
  
> This is different from the NonEmpty list issue, which still is working on
> avoiding the dangers of foolish users--who define an empty layout list--but
> in that case those foolish users could actually crash xmonad, rather than
> simply defining a key binding that has no effect.

And that issue is fixed today, too,
    safeLayouts = case defaultLayouts of [] -> (full, []); (x:xs) -> (x, xs)

I think the combination of a Message class, and the non-empty layout
handled via another mechanism, covers the holes we opened up.

-- Don


More information about the Xmonad mailing list