Hy, is there any chance we might get real tabbing support in xmonad? Ill try to explain what I mean by that: I often use the "Tall" Layout. It would be nice If I could take any frame and apply a tabbed layout on it so that I can open several windows within that frame and get some tabs. Currently I cant get this behaviour because I have to select the frames where I want tabbing uppon compiletime and there is no keybinding for switching the tabs. So what I'm searching for is: 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. Is it possible at all? I'm not into the xmonad sourcecode but perhaps the stack-set datastructure is not the right choice for this features. Perhaps some developers can tell about this. This is the only feature which im missing and which could make me go to ion3 because everytime I see a ion3 I love this feature. So, lets discuss! -- Dominik Bruhn mailto: dominik@dbruhn.de
dominik:
Hy, is there any chance we might get real tabbing support in xmonad?
Ill try to explain what I mean by that: I often use the "Tall" Layout. It would be nice If I could take any frame and apply a tabbed layout on it so that I can open several windows within that frame and get some tabs. Currently I cant get this behaviour because I have to select the frames where I want tabbing uppon compiletime and there is no keybinding for switching the tabs.
So what I'm searching for is:
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.
Is it possible at all? I'm not into the xmonad sourcecode but perhaps the stack-set datastructure is not the right choice for this features. Perhaps some developers can tell about this.
This is the only feature which im missing and which could make me go to ion3 because everytime I see a ion3 I love this feature.
I think with care and patience it is doable.
Dominik Bruhn wrote:
Hy, is there any chance we might get real tabbing support in xmonad?
Ill try to explain what I mean by that: I often use the "Tall" Layout. It would be nice If I could take any frame and apply a tabbed layout on it so that I can open several windows within that frame and get some tabs. Currently I cant get this behaviour because I have to select the frames where I want tabbing uppon compiletime and there is no keybinding for switching the tabs.
So what I'm searching for is:
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.
Is it possible at all? I'm not into the xmonad sourcecode but perhaps the stack-set datastructure is not the right choice for this features. Perhaps some developers can tell about this.
This is the only feature which im missing and which could make me go to ion3 because everytime I see a ion3 I love this feature.
So, lets discuss!
I suspect I'm not alone in pondering this one off and on. It's a common request. There are some questions of the interface, whether mod+j/k switch panes or tabs, but there are sensible defaults and room for customization. Build a TabbedTall layout specifically would likely be a little tricky, but perfectly possible. The bigger question is whether it would be possible to implement this as a LayoutModifier that could be strapped atop any (well, most) other layouts. I suppose it could keep a list of lists of windows, and give the underlying layout a list of "windows" which were actually the tabbed panes. My money is on possible, but it's nontrivial. I won't volunteer; I don't have the time to continue with my current xmonad-mangling project, ScreenWorkspaces. Taking 5 courses in one's major in one term is not recommended. Braden Shepherdson shepheb
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.
Moving between panes could be done with the already existing
WindowNavigation. But a cycle through panes should also be available.
I have been thinking about how signals would then propagate through
the combined layout. If this is implemented as a layout modifier, let
us say that all messages is sent to the outermost layout. Primarily
the layout modifier itself, but all unhandled messages is sent to the
layout that is splitting the panes.
Furthermore if a new message class is introduced, let us call it
PropagateMessage for now. If we wish to send the message to an inner
layout the message oldMessage is encapsulated in PropagateMessage. The
layout modifier decapsulates this message and sends it to the layout
which handles the window that is focused.
It may seem cumbersome to write keybindings for this, but I think it
could easily be solved by a recursive submap. Each time the submap is
entered another PropagateMessage would be added infront of all
messages that are sent. This solution is very similar to what is seen
in the terminal application screen where the sequence "ctrl-a a" sends
a "ctrl-a" to the screen inside.
The biggest problem about the behaviour I can see is how to start
placing windows in a new pane. Any ideas?
Moving windows from pane to pane is solved by WindowNavigation.
Swapping panes with eachother should not be too hard to solve.
On Wed, Feb 11, 2009 at 19:44, Braden Shepherdson
Dominik Bruhn wrote:
Hy, is there any chance we might get real tabbing support in xmonad?
Ill try to explain what I mean by that: I often use the "Tall" Layout. It would be nice If I could take any frame and apply a tabbed layout on it so that I can open several windows within that frame and get some tabs. Currently I cant get this behaviour because I have to select the frames where I want tabbing uppon compiletime and there is no keybinding for switching the tabs.
So what I'm searching for is:
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.
Is it possible at all? I'm not into the xmonad sourcecode but perhaps the stack-set datastructure is not the right choice for this features. Perhaps some developers can tell about this.
This is the only feature which im missing and which could make me go to ion3 because everytime I see a ion3 I love this feature.
So, lets discuss!
I suspect I'm not alone in pondering this one off and on. It's a common request. There are some questions of the interface, whether mod+j/k switch panes or tabs, but there are sensible defaults and room for customization.
Build a TabbedTall layout specifically would likely be a little tricky, but perfectly possible. The bigger question is whether it would be possible to implement this as a LayoutModifier that could be strapped atop any (well, most) other layouts. I suppose it could keep a list of lists of windows, and give the underlying layout a list of "windows" which were actually the tabbed panes.
My money is on possible, but it's nontrivial.
I won't volunteer; I don't have the time to continue with my current xmonad-mangling project, ScreenWorkspaces. Taking 5 courses in one's major in one term is not recommended.
Braden Shepherdson shepheb
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
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
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.
So .. in general terms maybe this could be done by creating a new
window stack in combineTwo (derivating from the orinal stack that is
applied to) and let one layout handle one stack and the other, the
other :) (don't know if it's actually possible). And of course
providing bindings for panel movement.
A more general approach would be the possibility to have multiple
panels in each screen, each managing its own window stack. Here's how
the workflow of this approach could be:
* Create a window, it goes to the master panel of the Tiled layout
* Create another window
* Move back to master
* Apply Mod+Something to make a new panel on it, a new panel is
created with the focused window as it only window. (now mod+j/k don't
work, since you're trapped in the new panel, maybe mod+h/l will be
suitable for changing panels)
* Create a new window, the window is created as a second window in the
new stack.
The thing here is how to decide on layouts, we'have a layout for each
panel, wich I suppose the default layouts will apply, and one Screen
layout that arranges the Panel, but probably for start an existing
layot like DragPanel or TwoColumns, when there are 2 panels, and Grid
when they're more could be used.
But I don't see this coming without affecting the core ...
byebye!
On Wed, Feb 11, 2009 at 4:44 PM, Braden Shepherdson
Dominik Bruhn wrote:
Hy, is there any chance we might get real tabbing support in xmonad?
Ill try to explain what I mean by that: I often use the "Tall" Layout. It would be nice If I could take any frame and apply a tabbed layout on it so that I can open several windows within that frame and get some tabs. Currently I cant get this behaviour because I have to select the frames where I want tabbing uppon compiletime and there is no keybinding for switching the tabs.
So what I'm searching for is:
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.
Is it possible at all? I'm not into the xmonad sourcecode but perhaps the stack-set datastructure is not the right choice for this features. Perhaps some developers can tell about this.
This is the only feature which im missing and which could make me go to ion3 because everytime I see a ion3 I love this feature.
So, lets discuss!
I suspect I'm not alone in pondering this one off and on. It's a common request. There are some questions of the interface, whether mod+j/k switch panes or tabs, but there are sensible defaults and room for customization.
Build a TabbedTall layout specifically would likely be a little tricky, but perfectly possible. The bigger question is whether it would be possible to implement this as a LayoutModifier that could be strapped atop any (well, most) other layouts. I suppose it could keep a list of lists of windows, and give the underlying layout a list of "windows" which were actually the tabbed panes.
My money is on possible, but it's nontrivial.
I won't volunteer; I don't have the time to continue with my current xmonad-mangling project, ScreenWorkspaces. Taking 5 courses in one's major in one term is not recommended.
Braden Shepherdson shepheb
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
* 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.
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
participants (8)
-
Adam Vogt -
Anders Engström -
Braden Shepherdson -
Daniel Spoonhower -
Dominik Bruhn -
Don Stewart -
Ismael Carnales -
Kathryn Andersen