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