[Xmonad] darcs patch: make workspace tag not need to be a Num.

[David Roundy]

On Wed, Jun 13, 2007 at 09:43:39AM -0500, Spencer Janssen wrote:
> On Wed, 13 Jun 2007 06:44:01 -0700
> David Roundy <droundy at darcs.net> wrote:
> 
> > Hi all,
> > 
> > This is a change that's more pervasive than I'd originally intended.
> > The idea is to move away from the dependence on workspace tags being
> > integers from 0 to size s, so that we can easily have more friendly
> > tags, such as String.
> > 
> > This also could move us in directions of putting extra information in
> > the tag.  e.g. if we stored the (Layout, [Layout]) in the tag itself,
> > then we'd be able to eliminate one additional data structure, and
> > we'd have the benefit that the pure StackSet code could track our
> > layouts for us.  I'm not sure this is worthwhile, but the idea came
> > to me, as I was trying to figure out how you'd recognize which Layout
> > went with which Stack, and realized that they're tracked totally
> > separately, which seems more than a little silly.
> 
> I've wanted to get layouts into StackSet for some time now.  However,
> we need to figure out how to serialize layouts before we can make that
> change.

Hmmm.  I've thought about this and have two ideas, which work out to almost
the same thing.  I assume we'll have to add a field or two to the Layout
record, something like:

data Layout = Layout { ...
                     , showL :: String
                     , readL :: String -> Maybe Layout }

then writing out the layouts is trivial (we could even define a Show
instance for Layout itself).  Reading is trickier, since we have not one
readL function but many.  Still, reading isn't too hard:

readLayouts :: [String] -> [Layout]
readLayouts ss = concatMap readLayout ss
  where readLayout s = take 1 $ catMaybes $ map (\l -> readL l s) defaultLayouts

With a little care to avoid troubles with getting an empty list, we've got
a working solution.  If two Layouts claim to be able to read a single
serialized Layout, we accept the one that's first in the user's list.

There are fancier ways we could do this, if we wanted to respect the order
of layouts which is in the user's Config file, but those would break
features (which could be added) in which the user adds or removes layouts
from a workspace on a dynamical basis.  e.g. if a given application behaves
very poorly (and not easily reversibly) when put into a given layout, I
might want to remove that layout from the workspace I use with that
application.

We could also create a function to make a very simple show/read:

serializeLayout :: String -> Layout -> Layout
serializeLayout uniqueToken l = l { showL :: uniqueToken, readL = r }
   where r t | t == uniqueToken = Just l
             | otherwise = Nothing

so that it'd be easy to wrap up existing layouts.  They wouldn't preserve
their layout state, but they'd work as well as they currently do.
-- 
David Roundy
Department of Physics
Oregon State University