Re: [Xmonad] extensible layouts?

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