[Xmonad] extensible layouts?

[David Roundy]

On Wed, May 02, 2007 at 09:03:31PM -0500, Spencer Janssen wrote:
> On Wed, 2 May 2007 08:27:39 -0700
> David Roundy <droundy at darcs.net> wrote:
> 
> > Hi all,
> > 
> > I was wondering if there were any plans to add support for extensible
> > layouts to xmonad? I haven't really gotten any comments on my patch
> > to do so, and have no idea if the approach I sketched out is
> > considered unacceptable, foolish, or what not.  Or perhaps there's
> > just no real interest in extensible layouts by the other developers?
> 
> I'm interested, but slow ;).
> 
> Some comments about your patch:
> 
>  - I'd rather stay away from the parametricity on message type.
> Matching via Show is a bit ugly.  I think a better representation is:
> 
> > data Message = Shrink | Expand | Other Dynamic
> 
> Layouts can then match against the core constructors, then fromDyn and
> match against special messages.

We could certainly do this, but it seems rather ugly to me.  Why should
Shrink and Expand be special cases? Why not something more equitable, such
as:

type Message = Dynamic
data StandardMessage = Shrink | Expand

Then extension code wouldn't need *two* checks, first to see if the Message
is Other, and then to use fromDynamic to see if it's a recognized message.

>  - Should there be more messages?  Specifically, messages like:
> WindowAdd, WindowRemove, InitializeLayout, UnitializeLayout.
> Otherwise, layouts that need to keep per-window state will need to
> compare their state against the window list on each 'refresh' call.

I'd say we may as well wait until there's a use for these before adding the
interface.  Comparing state versus the window list costs a very little
amount of processor time (and very little code), while API complexity is
relatively expensive in terms of developer time (we'd need to always keep
things in sync).

>  - Can layouts do IO (or X ())?  I've seen a handful of requests for
> ion style tabbing -- this requires IO to draw the tab bar.
> Additionally, the layout would need to listen to arbitrary X events to
> redraw the tab bar on ExposeNotify events.

I'd say they'll definitely need to learn to do this, but that it should be
in a second refactor.  I don't think the design need be very different, and
we definitely want to support pure functional layouts as well.
-- 
David Roundy
http://www.darcs.net