On Fri, Feb 1, 2008 at 5:04 PM, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:

Excerpts from Brent Yorgey's message of Fri Feb 01 22:53:20 +0100 2008:

> On Thu, Jan 31, 2008 at 2:42 PM, Spencer Janssen <sjanssen@cse.unl.edu>
> wrote:
>
> > On Wed, Jan 30, 2008 at 07:29:58PM -0500, Brent Yorgey wrote:
> > > 1. PerWorkspace is an inelegant hack with several icky problems:
> >
> > Agreed. It is approaching the limits of xmonad's layout design. However,
> > I
> > think we can accomplish PerWorkspace behavior without changing too much.
> >
> > \begin{code}
> > data PerWS = PerWS { selected :: Maybe Layout
> > , choices :: Map WorkspaceId Layout
> > , default :: Layout }
> > \end{code}
> >
>
> So, I took a crack at implementing (something like) this today. The problem
> I ran into is that (Layout a) is not an instance of Read, so PerWorkspace
> cannot derive Read either. Is there any way around this? Or do I have to
> go back to caching a (Maybe Bool) and using that to decide on which of two
> layouts to use, instead of directly caching a (Maybe (Layout a))?
>
> Ideas?

What about "instance Read a => Read (Layout a)"?

Well, since Layout is an existential wrapper, that's not possible -- it hides the type of the wrapped layout. I know that lots of work has already gone into the xmonad core getting around this issue. =)

Hmm, just thinking out loud here... note that I don't actually care about being able to read the (Layout a) value back in, since after serialization/restart the startupHook will get run again anyway, and the correct workspace will get re-cached. So perhaps I can just write my own explicit Read instance for PerWorkspace that somehow ignores that element and just initializes the read value to Nothing. Sounds scary. =)

-Brent