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

On Wed, Jun 13, 2007 at 09:43:39AM -0500, Spencer Janssen wrote:

On Wed, 13 Jun 2007 06:44:01 -0700 David Roundy 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