[Xmonad] problems with self-modifying layouts

David Roundy droundy at darcs.net
Fri Jun 22 09:21:52 EDT 2007


Hi all,

(This email is partly a resend of content attached along with a patch,
which I realize folks might not have seen, since I sent a fixed version of
that patch.  If you come across this twice, and find it as boring the
second time as the first, my apologies.)

There's design problem with some of the recently-introduced self-modifying
layout modifiers, which include Decorations and SimpleStacking.  The
trouble is that while it's easy for a Layout to modify itself in response
to an event, there's no safe way for a layout to modify itself in during a
doLayout call.  One answer to that is to simply state that "layouts should
not do that."  This seems an unsatisfying answer to me, as we've already
got two valid uses--one already refactored into LayoutHooks, an inherently
buggy module.

The trouble is that within doLayout, there's no way for a layout to modify
itself, because it can't tell which layout it is... and because it may not
be a "root" layout at all, but some intermediate modified layout.  There
seems to be a simple solution:

data Layout a = Layout { doLayout :: Rectangle -> Stack a
                                  -> X ([(a, Rectangle)], Maybe (Layout a))
                       , modifyLayout :: SomeMessage -> X (Maybe (Layout a)) }

so doLayout can modify itself.  This makes all the Layout transformers a
little harder to write, but a helper module ought to be able to fix that.

And it makes me wonder yet again whether we should be defining a class

class Layout l a where
   doLayout :: l -> X Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (Layout a)
   modifyLayout :: l -> SomeMessage -> X (Maybe (Layout a))
   serializeLayout :: l -> String
   readLayout :: String -> Maybe (l, String) -- or some other parser-like thing

data Layout a = forall l. Layout l a => Layout a

This might lend itself to somewhat prettier Layout code that is more
"data-structure-based" rather than self-modifying-function-based.  I
imagine this would lead to friendly interfaces for easy-to-write layout
modifiers.

David

P.S. I'd be curious to see implemented a "popularity-contest" module for
xmonad once we've got serialization, which could use the logging mechanism
to report on the most frequently used layouts.  And yes, this would be in
XMonadContrib and only manually enabled.  I have no idea how many people
are actually using Tabbed, and how likely this is to break folks' Config
files.


More information about the Xmonad mailing list