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? 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. (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). 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 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. -- David Roundy http://www.darcs.net