Hi all, I've had another idea for how we might implement configurable layouts, which would have the advantage (or disadvantage?) of removing the tileFraction from the StackSet, and moving it into the layout itself. I don't have time just yet to hack this up, but thought I'd run the idea by you. The idea is to have a type Layout which holds whatever information is needed to determine how to lay out the windows: data NewLayout = L { doLayout :: Rectangle -> [Window] -> [(Window, Rectangle)] , modifyLayout :: Event -> Maybe NewLayout } The doLayout does the actual laying out (e.g. calls tile or vtile). The second function, modifyLayout would be in charge of updating whatever state there might be (e.g. changing the tileFraction. A very sketchy example would be this sketch of the Tall layout: tall :: Rational -> NewLayout tall tileFraction = L { doLayout = tile tileFraction , modifyLayout _ = Just $ tall (tileFraction*1.5) } Obviously modifyLayout is just wrong, but I don't have all that much time. The point is that it'd be able to update the tileFraction, and by using closures like this, we wouldn't have to hard-code what extra data (e.g. tileFraction) needs to be stored with each workspace. The catch is that I've changed the semantics, as each layout will now have its own tileFraction. I don't think that's a Bad Thing, but you may disagree. The other controversial (or at least it's controversial to my mind) aspect of this is the use of Event in modifyLayout. It's pretty ugly (particularly with regard to key bindings), but I can't see how else to allow a tabbed layout to respond to mouse clicks. I imagine we'd need some sort of translation layer to make keybindings pretty... but I can't solve all the worlds problems overnight. Anyhow, this is the closest I've come to imagining a StackSet data format that will allow for the implementation of clever new layout algorithms, which might need some extra data, and will certainly need to respond to extra events. I should also mention that I imagine mod-space working by storing a list of layouts for each workspace, and rotating between them. Obviously, when you change layout, you'd like to keep the old one so you can go back to it (e.g. so you can switch to fullscreen and back without losing your tileFraction). -- David Roundy http://www.darcs.net