[Xmonad] Less code smell for xinerama code

[Donald Bruce Stewart]

droundy:
> On Mon, May 21, 2007 at 04:07:40PM +1000, Donald Bruce Stewart wrote:
> > The same list, but with a hole punched in it to track focus:
> > 
> >         Cursor = { left    :: [w] 
> >                  , current ::  w 
> >                  , right   :: [w] }
> > 
> > We use the partitioning of the this punched list to separate those
> > workspaces that are visible on a xinerama, but not in focus, and those
> > that are hidden entirely.
> > 
> >         Cursor = { visible :: [w] 
> >                  , current ::  w 
> >                  , hidden  :: [w] }
> > 
> > That is, the workspaces to the 'left' of the currently focused workspace
> > are now only the xinerama-visisble ones, and those to the 'right' are
> > those that are completely hidden. The result, much less bookkeeping, and
> > 4 dynamic checks are removed, as the data structure tracks them by
> > design. 
> 
> It seems that the "order" of workspaces doesn't seem to be preserved.  This
> could be an issue if we want to have reproducible cycling of workspaces.
> But then again, I've no idea how cycling *ought* to work on xinerama, and
> since visible is always empty for me, but without xinerama, we're reduced
> to a single list.  It'd be nice if that list were always maintained in a
> fixed order, so that (for example) rotView wouldn't need to defined sortWs.
> Or alternatively, we could go back to using a zipper for the workspaces, so
> that rotating through the workspaces would be easy.

Though that re-introduces separate handling of xinerama, which is
tedious. Having an easy way to get at hidden and visible seems nicer,
imo. And its easy to pick a fixed order based on tags.

> Incidentally (and almost unrelated), I've been toying with the idea that
> the tags could be strings, much like ion does, so the user could name his
> workspaces ("iceweasel", "mutt", etc), which could lead to nice dmenu
> integration for switching workspaces.  I guess this means I'm (sort of?)
> retracting my vote for removing the tag.

A contrib module could map strings to tags, I think?

-- Don