droundy:
On Thu, May 17, 2007 at 02:19:03PM +1000, Donald Bruce Stewart wrote:
I've written up the idea behind implementing xmonad as a zipper-based data structure which tracks focus for us here,
http://cgi.cse.unsw.edu.au/~dons/blog/2007/05/17#xmonad_part1b_zipper
For those wondering how the new StackSet data type will work. The plan is to merge in my zipper branch in the next few days.
I have a few comments.
First and foremost: it seems that your zipper idea is taking a change in the user interface, and expressing it in the data structure. Wouldn't it make more sense to first have the discussion of what user interface is desired, and then implement it afterwards? Or did this discussion already occur on IRC, and everyone agreed that they didn't like the focus-stack behavior?
Right, its an attempt to implement the delete . insert == id model of focus behaviour, which is the alternative to the focus stack model. I promised to go off an implement this when we talked about the focus stack idea, on irc, I think. So this is a behaviour change from the focus stack code comitted while I was away. I prefer it, since it is much simpler to understand the focus movement behaviour, which fits with out goals of full predictability of each operation. Surely focus stack handling is an elaboration that could be achieved via a contrib module?
Personally, I prefer the idea of a focus stack, but will concur that your non-stack approach isn't much worse. And the data structure is certainly beautiful--except that it presumes that there exists a fixed layout based on order of windows, which I don't prefer as a UI. But I understand that most of you do.
Or more that it tries to return the same window list as the current implmentation, while tracking focus in a more obvious manner. A focus tracking workspace is just the one-hole context of a stack, after all! :-)
(totally different--related--topic...)
The dynamical number of workspaces is one of the reasons I like ion3--and it's something your current code change would remove from xmonad. It's not advertised, but the number of workspaces is fixed in xmonad only because of the default choice of key bindings, and I like that. I certainly have been using a dynamical set of workspaces via emulation (and someone else is doing the same, see FindEmptyWorkspace).
Now this is interesting, and I see no obvious reason not to do this.
And actually, I have just one idea specific to your suggested API:
new :: Int -> StackSet a new n | n > 0 = StackSet t [] rs where (t:rs) = [ Workspace i Empty | i <- [0 ..n-1]]
Why not make this
empty :: StackSet i a insertWorkspace :: StackSet i a -> StackSet i a -- insertWorkspace sets the focus on the new workspace, and works like -- insert does on windows, obeying the same properties. deleteWorkspace :: i -> StackSet i a -> StackSet i a
This gives us control of workspaces if we choose, and costs you nothing. For those of us who like RotView, and FindEmptyWorkspace, we'd get these behaviors for free, and those who prefer to have a fixed number of (possibly empty) workspaces, they could have that for free also.
And of course,
new n = foldr (const insertWorkspace) empty [1..n]
I'd also vote for removing the tag :: Int from the Workspace. It only costs O(N) to count workspaces to get to the Nth one, and N in general is a small number. And the common operations are all O(1) since they access the first workspace. The behavior wouldn't be affected, except that
Yes, that's true. We could avoid the tag -- its not terribly useful. Its been pointed out that the 'master' tag is also not required, since the 'integration' (idea from Conor's zipper paper :-) of the Stack cursor gives us the list with master at the top anyway.
insertWorkspace could change the numbering scheme. But, I don't see that as a real problem. You currently don't have an API for insertWorkspace, and I expect that those who use it will easily adapt to the idea that it works the same as windows.
Yes, I think we can look at this next. -- Don