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