[Xmonad] A plan for the floating layer

[David Roundy]

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.
-- 
David Roundy
Department of Physics
Oregon State University