[xmonad] specific layout per workspace

[Brent Yorgey]

On Nov 19, 2007 3:39 PM, David Roundy <droundy at 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 at gmail.com> wrote:
> >
> > >
> > > On Nov 19, 2007 12:11 PM, Don Stewart <dons at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/xmonad/attachments/20071119/7e833d34/attachment-0001.htm