On Wed, Feb 11, 2009 at 08:03:30PM +0100, Anders Engstr?m wrote:
Dominik Bruhn wrote:
1. A Keystroke which makes the current frame tabbed 2. A possibility to shift a window into a frame (so it gets another tab) and out again. 3. The current Keybindings like Mod+{j,k} stay the same, they dont switch tabs. 4. New Keybindings for moving to the next tab in the current frame.
Let me second this idea with enthusiasm! I've managed to get almost something like this by multiple applications of Combo, DragPane and Tabbed, but it would it would be good if it could be a first-class LayoutModifier, applicable to any layout. (And it would be nice if one could have a choice between "display tabs only when needed" and "display tabs always" with it too)
I think the most logical would be to let mod+j/k switch tabs and when there are no more tabs go to the next pane. This way, they will keep the same functionality. Other bindings (messages) should then be created to handle cycling through tabs or panes separately.
The important thing is to be able to have different keybindings for switching tabs and for switching panes, since one might wish to do one or the other without having to cycle through everything in between first.
The biggest problem about the behaviour I can see is how to start placing windows in a new pane. Any ideas?
I agree this is an important problem to solve. The difficulty is that Ion and Xmonad approach the creation of panes differently. If I recall correctly, with Ion, you create a pane, and then you add windows to it; a new window is tabbed into the current pane. But with Xmonad, you have a stack of windows which you then arrange according to rules; in one sense, it doesn't have the concept of panes, just of windows. Let me give an extended example, to illustrate the problem. With the Tall layout (with one Master), it goes like this: 1 window - takes up whole screen 2 windows - two windows side-by-side 3 windows - one tall window on left, two windows on right, splitting the column equally. 4 windows - one tall window on left, three windows on right, splitting the column equally. And so on. But with a proposed RealTabbed Tall, how does one determine when to tab a window, and when to let it be managed by the underlying layout? Some people might like tabbing to happen when you reach 3 windows, others with 4 windows... I suppose you could have that as a parameter to RealTabbed - how many windows to pass through before tabbing is applied, that might work. So long as one could also move windows between panes as well. I mean, like this: Suppose you said "I want a three-window Tall"; the behaviour would be like this: 1 window - takes up whole screen (managed by Tall) 2 windows - two windows side-by-side (managed by Tall) 3 windows - one tall on left, two on right (managed by Tall) 4 windows - one tall pane on left (with the 4th window tabbed), two panes on right; the panes managed by Tall, the tabbing done by RealTabbed. Then suppose someone wants to move one of the windows on the right to the left pane; what one might want would be two columns side-by-side (managed by Tall) with the left-hand column having three tabbed windows in it. In other words, make the underlying Tall think that there are only two windows to manage. Then, someone moves one of the windows to the right, and Tall is told "hey, three windows!" and we get the one-pane-on-left, two-panes-on-right behaviour. As for the question of "how do we map new windows", I think it would go like this: Do we have fewer panes than are managed by the underlying layout? If true, pass the new window to the underlying layout to manage. If false, tab the window into the currently focused pane. Kathryn Andersen -- _--_|\ | Kathryn Andersen http://www.katspace.com / \ | \_.--.*/ | GenFicCrit mailing list http://www.katspace.com/gen_fic_crit/ v | ------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere Maranatha! | -> Earth -> Sol -> Milky Way Galaxy -> Universe