PoC: FlexibleRead -- layout settings that survive a layoutHook change

Hello, I'd like to announce a proof of concept I wrote over the weekend. In my previous mail (about dynamic workspace names) I mentioned that WorkspaceDir settings are lost whenever the layout hook changes, even if it is the outermost layout modifier. Realizing that the layout is essentially a tree, I walked up to a whiteboard and found a solution. What I ended up doing was that I have a typeclass for reading and writing a layout from/to a tree, and instances for ModifiedLayout, NewSelect and generic layouts. This alone solves the problem of outermost modifiers, since the tree can always be read, and I call reads for each modifier separately, replacing it from a default value if it fails. For all this to work, the Read instance for my modifier needs to have a default value at hand, and this is done by a snippet of template haskell that defines a Read instance for the very type of a particular layout and provides the default value to the reading function. Without TH, one would have to write the complete type into the instance head manually. Finally, an algorithm that takes the old layout tree, new layout tree, and tries to pass the configuration from the old one to the new one, if it changed, is plugged into the Read instance. The algorithm is accompanied by a few quickcheck properties that ensure that certain simple modifications are fully recoverable: - change of the order of layouts in NewSelect, as long as they are distinguishable (which mouseResizableTiled and its mirrored variant are not, but I'll send a patch for this later), - change of one of the outermost modifiers, as long as it's not anywhere else in the tree (this probably be improved), - addition of a layout (a layout chain, in fact). It uses a very crude heuristic that can be certainly made better. The code resides in my config repository at [1]. The configuration is pretty simple, just add a flexibleRead in front of the layout, and then have flexibleReadInstance derive the instance for you. Have a look at my xmonad.hs if in trouble. [1] http://anna.fi.muni.cz/~xjanous3/darcs/xmonad-conf/ It is just a proof of concept, it is quite ugly, and I'm hoping for some insightful comments. One that comes to my mind is that we can at least get rid of template haskell if xmonad core used some other Read type class that had the ability to provide a default value (but hey, isn't is a nice use of it after all? :-)). Regards, -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
participants (1)
-
Tomáš Janoušek