Excerpts from Mario Pastorelli's message of Mon Dec 12 17:44:58 -0700 2011:
I have decided to post my patch to improve GridSelect so that you can choose the grid shape and you can sort elements. I decided to do this patch because I don't like the idea to use a diamond grid for my workspaces without any order. It is too confusing for me. With my patch gridselect can show workspaces in a row sorted by tag.
The defaultGSConfig has not been touched so that my patch will not break existent configuration using that. If you want to show and sort workspaces in a row you can change your xmonad.hs by putting this:
gridselectWorkspace defaultGSConfig { gs_shaper = line, gs_elementSort = sort }
where sort is the function from the list module.
I'm not a GridSelect user, so I've not actually run the new code, but the patch applied cleanly. Quickly looking over the code, it seems sensible, and looks like it would be helpful for some gs users. It looks like it would be easy to plug in other shapers and sorts as people want them. The main suggestion I'd make (as a user, not a patch committer or expert) would be to modify the documentation a little. This could of course be a separate patch once this one's pushed. * I'd move the `Shapers' section up before `Screenshots', (after Navigation Components.) Also I'd move the type TwoDShaper into that section. Then, most important, I'd briefly document 'diamondRestrict' and 'line', and how the new gs_elementSort field affects the shapers. Maybe even include a line screenshot to get the point across really quickly. * Nitpick? The new gs_elementSort lets the programmer work out how to sort (String, a) for a's that have no Ord instance (like Rectangle) so that's okay. I'm not familiar enough with gridSelect to know if some doc examples using Data.List.sort might not work for some a's. For completeness' sake I'll include another nitpick, even though I wouldn't change anything as a result: * It looks a minor config breakage could result from inserting the new GSConfig fields rather than appending them. It's not likely this would affect many people (if any.) Probably everyone uses defaultGSConfig with record syntax, or buildDefaultGSConfig, instead of (pre-patch): GSConfig 40 90 5 someColorizer "font" fooNavigation 0.5 0.5 IMO, the advantages outweigh the drawbacks since keeping the gs_originFract* fields last is more readable. Thanks Mario! --wmw