[xmonad] Select grid shape and sort elements for XMonad.Actions.GridSelect

[Wirt Wolff]

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