[Xmonad] xmonad is a zipper

[David Roundy]

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