When splitting twice into three panes, I would like the option to split by parent equally.
Instead of:
| | | |
+-------+---+---+
Ideally it would be like this:
| | | |
+----+----+----+
Coming from iTerm this makes much more sense to me.
When splitting vertically within a horizontal pane, it would work in the same fashion.
This could be a new shortcut that when splitting, e.g. "split horizontally and keep parent" where all children are resized when a new child is added or removed. (I don't how how it currently works internally, so I'm guessing here.)
Love this idea. A few thoughts off the bat.
We could accomplish this by adding a keybinding argument to the splitPane action.
Getting inspiration from TabView's TabWidthBehavior (doc), we could introduce a keybinding argument like splitBehavior with the following possible values:
equal: each pane is resized to have the same size (this feature)half: split the space in half for two new panes (current behavior)I'm guessing we would have to have this same keybinding argument for closePane?
Regardless, we probably need a spec for this so I'll tag it up now.
my napkin spec was { "action": "splitPane", ..., "resizeParents": true }, to walk up the tree and re-adjust splits with the same direction, until we hit a split with a different direction.
Consider creating a bunch of similar splits:
+-----+-----+ +---+---+---+ +--+--+--+--+
| | | | | | | | | | | |
| | | | | | | | | | | |
| a | b | | a | b | c | |a |b |c |d |
| | | | | | | | | | | |
| | | | | | | | | | | |
+-----+-----+ +---+---+---+ +--+--+--+--+
This makes sense, each takes not half the parent, but 1/Nth of the whole
Then consider splitting B in the following:
+-----+-----+ +-----------+
| | b | | |b |d |
| | | | | | |
| a +-----+ | a +--+--+
| | c | | | c |
| | | | | |
+-----+-----+ +-----+-----+
We probably don't want to make A, B, D all take 33% width here (leaving C with 66% width)
How about resolving this more generically with 2 new options - SplitHereVertically and SplitHereHorizontally based on mouse/cursor position. This would allow for maximum flexibility of pane sizing, and then the "parent resizing" becomes mandatory.
I definitely second this suggestion, even though it looks like this original suggestion might be "waylaid" by now after a year or so.
Use case here is for research, running multiple simulation, perhaps 8. That means 8 command line windows. It would be really helpful to see progress on all at the same time without switching tabs all the time, i.e. you want equally spread windows (ideally horizontally split). Shift+Alt+- etc. is great, but it's exponentially decreasing in size. Using the mouse to configure the 7 splits manually every time there is a run is not practical. Therefore you want it to automatically adjust the already existing splits to accommodate the new one, OR allow specification of number of splits, like 8, ahead of time so it knows how to split equally in one go.
I'm sure this kind of simulation/research runs are not a corner case for this app, as running multiple old-fashioned command lines is the only other option, where you have auto tile etc available in native Window GUI. This actually can work well. However, if you have any other windows open other than the consoles, it messes up and doesn't work at all.
Most helpful comment
Love this idea. A few thoughts off the bat.
We could accomplish this by adding a keybinding argument to the
splitPaneaction.Getting inspiration from
TabView'sTabWidthBehavior(doc), we could introduce a keybinding argument likesplitBehaviorwith the following possible values:equal: each pane is resized to have the same size (this feature)half: split the space in half for two new panes (current behavior)I'm guessing we would have to have this same keybinding argument for
closePane?Regardless, we probably need a spec for this so I'll tag it up now.