Some more changes to the Xinerama code just landed: we removed the separate table tracking Xinerama screens to virtual workspaces. Instead the core data structure now tracks directly the current, visible and hidden workspaces. Makes policy regarding how workspaces are moved around on xinerama screens a lot simpler. The trick is to use the 'one hole context' workspace list (a list with a hole punched in it to track focus). A list of workspaces: Workspaces = [w] 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. Moving between current and visible workspaces becomes obvious to implement and test, and deciding when and how to raise a hidden workspace also becomes easy. Finally, we have a natural account for the concept of 'visible but not current' workspaces, as managed by Xinerama, directly in the StackSet data structure. The result being code that doesn't smell quite so much. -- Don
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. 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. -- David Roundy http://www.darcs.net
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
participants (2)
-
David Roundy -
dons＠cse.unsw.edu.au