Re: [xmonad] The future of PerWorkspace

Excerpts from Brent Yorgey's message of Fri Feb 01 23:08:30 +0100 2008:

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

...

...

On Thu, Jan 31, 2008 at 2:42 PM, Spencer Janssen 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

Excerpts from Brent Yorgey's message of Fri Feb 01 22:53:20 +0100 2008: 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. =)

Yes, I didn't understand why this line compile and seems to solve the problem. Indeed I've encountered this same issue while doing another xmonad extension. -- Nicolas Pouillard aka Ertai