[xmonad] Re: Real Tabbing?

[Daniel Spoonhower]

Maybe I am getting off-topic, but this tabbing discussion is making me
think about a bigger picture involving the floating layer and switching
between workspaces.

If I understand things, we currently have a set of workspaces of which
we display one per screen.  Each workspace has a stack of windows and a
layout.  Of the displayed workspaces, one is active.   If we ignore
hooks, new windows are sent to the active workspace.  And (of course) we
have ways of sending windows from one workspace to another.

What if we were to allow *more* workspaces to be displayed?  That is,
more than one per screen?  For example, we might split a screen into two
"frames" (or maybe "panels" if you prefer) and put a different workspace
on each frame.  Or that we might display one workspace on top of another
-- useful with a non-tiling layout (e.g. the floating layer) or with
transparency (or both).

There have been a couple of recent posts that make me think that tabbed
panels, floating layers, and workspaces are all really the same thing.

>From a thread on tabs [1]:
> 2. A possibility to shift a window into a frame (so it gets another tab) 
> and out again.
If you substitute "floating layer" for "frame" then this sentence still
makes sense (ignoring the parenthetical).  We already have a way to
shift windows into and out of the floating layer.  It also makes sense
if you substitute "workspace" for "frame" and, of course, we already
have a mechanism for shifting between workspaces.  Could all these
mechanisms be combined?

>From a thread switching between workspaces [2]:
>  ... so that mod-Right would switch focus to the next window to
>  the right until it reached the edge of the screen, and then the
>  next press would switch focus to the leftmost window on the
>  Xinerama screen to the right of the one where I just was.
This would also make sense in the context tabs and frames.  (Though
different users might have different preferences about switching within
a panel/workspace as opposed to between them.)  Making floating layer
another workspace would (I think) also fix the weird alt-tab ordering
problems that arise because of the interleaving of floating windows and
non-floating windows in the same stackset.

What I'm proposing would require something like:

  - a mechanism to display a workspace on a portion of a screen (this
    may overlap with the portion used to display another workspace)
  - a mechanism to move focus from the last window in one workspace to
    the first in another workspace (e.g. a proposed solution to [2])
  - a separate non-tiling layout for managing the floating layer

This would allow for one floating layer per "normal" workspace (like we
have now), or just one global floating layer (more like Mac OS X
Dashboard).  Or some other behavior as defined in XMC!

Anyway, I have been a happy if somewhat blissfully ignorant user for a
while, and it's possible that I am just making things up and ignoring
some important issues.  Still, from my point of view, it would be nice
to fix the the behavior of the floating layer (which to me is the only
time I ever have to *think* while using XMonad) and maybe make some
others happier as well.


Cheers,

--spoons

[1] http://www.haskell.org/pipermail/xmonad/2009-February/007332.html
[2] http://www.haskell.org/pipermail/xmonad/2009-January/007133.html


Adam Vogt wrote:
> * On Thursday, February 12 2009, Ismael Carnales wrote:
> 
>> I think the biggest problem here is when you combinate two layouts and
>> only get one stack, the new opened windows always go to one layout or
>> get trickier results. Also you track one real focus point because you
>> get only a stack.
>> ...
>> But I don't see this coming without affecting the core ...
> 
> Though it isn't as pleasant as having all state information in the 
> StackSet, but you can have a Data.Map.Map from windows to the state that 
> you need to keep track of for each window.
> 
> Data.Layout.MosaicAlt does this to keep track of each window's prefered 
> size and aspect ratio.
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>