[Xmonad] A plan for the floating layer

[Donald Bruce Stewart]

droundy:
> On Thu, May 31, 2007 at 05:59:05PM -0600, Jason Creighton wrote:
> > On Thu, May 31, 2007 at 07:17:09PM +1000, Donald Bruce Stewart wrote:
> > >     data Workspace i a = Workspace  { tag :: !i
> > >                                     , tiled :: Stack a
> > >                                     , float :: Stack a }
> > 
> > With that, you know which window has the focus in each layer, but how
> > would you know which layer has focus? Also, you need to store the
> > RationalRect with their x/y/w/h information somewhere. Are you thinking
> > of retaining the "floating" map? Or float :: Stack (a, RationalRect)?
> 
> What about something like:
> 
> data Workspace i a = Parent { tag :: !i
>                             , child :: Stack (Workspace a) }
>                    | Workspace { tag :: !i
>                                , thewindows :: Stack a }
> 
> Then we can put two or more workspaces together, and the same set of
> functions can be used to track focus, etc.  This would naturally allow for
> multiple sets of floating windows (sticky, etc).  Maybe it's overkill, but
> when I see the same problem come up again and again (screens each have a
> single workspace focussed, "tiled" has a single window focussed, "float"
> has a single window focussed, workspaces each have one of "tile" or "float"
> subworkspace focussed, I think that reuse of code sounds like a good plan.
> 
> Or maybe, if we didn't want arbitrary nesting, we'd want "what's visible on
> a given screen" to be of type
> 
> data ScreenContents i a = ScreenContents { tag :: !i
>                                          , thechildren :: Stack (Workspace a)
>                                          }
> data Workspace i a = Workspace  { tag :: !i
>                                 , thewindows :: Stack a }
> 
> We'd reuse the same focus code we've already got.  Either way (my approach
> or dons' suggestion) we have to decide on how to deal with things like
> window focus cycling (does it cycle through float and tiled windows
> separately?)  But my suggestion could lead to (I think) a more natural
> replacement for the docking work, for example.  A dock could be just
> another Workspace, which might be visible on many or all of your
> ScreenContents'.
> 
> I can't see to the end of this idea, how it'd all work, but it seems like
> the elegant direction to move.  Of course, one would want to move
> gradually.  On the other hand, if dons (or someone else) came up with a way
> to represent the nested workspace as a tree-like zipper, maybe everything
> would suddenly become simpler.  This sounds a lot like the zipper idea
> coming back at us.

Yes, the more I ponder it, the more two layers really appears to act
like a 2 level tree zipper. Focus is the current node, in the current
layer, on the current workspace.

The new idea is the layer separating floating and tiled windows. Some
ops would traverse both. 

i'll think more about this tonight. If we find the right data structure,
the code, and the right UI, will follow.

-- Don (practicing zen in the art of coding)