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

On Wed, May 02, 2007 at 09:03:31PM -0500, Spencer Janssen wrote:

On Wed, 2 May 2007 08:27:39 -0700 David Roundy 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