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@haskell.org http://www.haskell.org/mailman/listinfo/xmonad