On Nov 19, 2007 3:39 PM, David Roundy <droundy@darcs.net> wrote:
On Mon, Nov 19, 2007 at 02:13:41PM -0500, Brent Yorgey wrote:
> On Nov 19, 2007 1:45 PM, Brent Yorgey <byorgey@gmail.com> wrote:
>
> >
> > On Nov 19, 2007 12:11 PM, Don Stewart <dons@galois.com> wrote:
> >
> > > lobzang:
> > > > Hi guys,
> > > >
> > > > Is there any way to configure xmonad in order to have a custom layout
> > > per
> > > > workspace, for exemple :
> > > > workspace 1 (xterm) : Layout $ Mirror tiled
> > > > workspace 2 (web)   : Layout Full
> > > > workspace 3 (icq)   : Layout tiled
> > >
> > > This is a great idea, I wonder why we haven't thought of it before!
> > > There /must/ be a way to do it. Anyone have some thoughts?
> >
> > Hmm, it seems like it would be possible to create a LayoutClass instance
> > for something like (WorkspaceId -> Layout Window), which does layout by
> > first getting the state from the X monad and using the current workspace id
> > to select the layout to use.  Perhaps I'll take a crack at it, unless
> > someone thinks this isn't a good idea for some reason.
>
> I just realized this would cause major problems for serializing layout
> state!  Perhaps a Map from WorkspaceId to Layouts would work -- slightly
> less flexible, but it would work with serialization/layout preservation
> across restarts.
>
> Anyone have any comments/thoughts?

I'd prefer a function :: WorkspaceId -> Layouts rather than a Map.  A Map
will always leave you with possible runtime failure cases.  A function
might be incomplete, but that's not as bad (in my opinion).
 
Well, after thinking about it some more, I decided to go with a completely different, third option. =)   I made a PerWorkspace layout which is very similar to NewSelect from LayoutCombinators, except that it is constructed with a workspace tag as well as two layouts.  On the workspace which matches the tag, it chooses the first layout; on any others, it chooses the second.  Of course, multiple per-workspace layouts can be defined by chaining PerWorkspace.  This also has the advantage that the problems that would be caused by a partial (WorkspaceId -> Layout) function are impossible; if no workspace tags match, the layout selection will simply fall through to a default, which is guaranteed to exist by the type system.  Serialization/deserialization is also easy. 

I've got a proof-of-concept working but I'll have to work a bit more on documentation, testing, etc., hopefully I'll have it up in darcs within a few days.

Serialization here is an interesting problem.

One option would be to create a container type that can contain various
types of layouts, something like a variant of Choose which can have one of
its layouts disabled.  This would allow us to avoid having any changes in
the serialization code, and would also work nicely with dynamic changes of
layout options (removing or adding options from a given layout).  I have no
idea how it can be made palatable in the config file... but I've got to go
now.

I'm not entirely sure that I follow you, but some interesting ideas in here nonetheless.  It's quite possible that this could be made into something more general.  Once I push it to darcs feel free to poke at it. =)
 
-Brent