[Xmonad] extensible layouts?

[Donald Bruce Stewart]

droundy:
> On Thu, May 03, 2007 at 10:48:36AM +1000, Donald Bruce Stewart wrote:
> > droundy:
> > > 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?
> > 
> > On the contrary! We *really* want to support arbitrary user layouts
> > specified in Config.hs (or elsewhere). I'd personally like ion-style
> > tiling. We've spent a bit of time talking about this on #xmonad.
> 
> Have my patches to enable this been discussed at all? If there's interest,

There were a few weeks ago, but the feeling then was that it was too
much, too soon, in terms of complexity, while we were busy getting 0.1
done.

The time has come to look at that again.

> I could bring them back up to date with the recent changes, but I'd rather
> first hear that the general principle is acceptable.  I think that storing
> the layout functions as functions which themselves hold whatever data they
> need in the functions themselves is quite elegant.  And I suppose if we're

Yes.

> willing to live with mutually recursive modules (which I personally
> despise), we could avoid the type-parametrization of the X monad that I
> introduced, by simply exporting the layout message type from Config into
> XMonad.

Which we already have (mutual recursion on Config.hs)

> 
> > > I'd rather not bother resolving the conflicts I've got with the recent
> > > burst of modifications if there's not much interest in the patch,
> > > particularly as my wrist has decided I shouldn't be using my computer very
> > > much--and I need to use one for work.
> > 
> > I think the best approach would be to work out a way to support user
> > Config.hs, and then just have submitted algos go into XMonadContrib.
> 
> I absolutely agree.  My XMonad repository was intended to function like
> this, only the interesting module (Mosaic) relies on the changes to allow
> extensible layout algorithms, which are now broken beyond the degree that
> I'm enthusiastic to fix them--without some sort of encouragement that this
> sort of approach is desirable.

Right. Basically what we need is something simple and clean: since users
are expected to write their own functions. But balancing this is the
need to have enough flexibility to get at any values a user might want
to utilise.

I'll read through your original submission again.

-- Don