feature request: 3-column layout

[quesada]

With many monitors in the 2600 x 1400 range, it's becoming more and more needed.

[jamartinb]

+1

[engelfrost]

+1

[cmlsharp]

+1

[Amxx]

Would be a really nice feature on 3200x1800 laptop !

[william-gr]

+1

[cmlsharp]

+1

[timbertson]

I don't have plans to implement this any time soon myself, but if anyone wants to submit a PR / patch, that'd be most welcome :)

[bufke]

+1 I'd be willing start a bounty on this.

[timbertson]

Closed? This isn't implemented, and there seems to be plenty of interest so I'm reopening. @quesada I think you can remove yourself from notifications by unsubscribing, if that's what you were after.

[AlexDunmow]

+1

[nzjrs]

+1 I'd be willing to put a bounty on this too.

[rhofour]

I don't have much use for a three column layout, but if there's a bounty I could probably spend the time and get this working.

How do people imagine this should work?

The simplest way to do this would probably be to make a new horizontal layout where the minor split is also horizontal. The default main split could be set to 1/3 and the minor split to 1/2 so that when three windows are tiled this way they're all equal width. I think this would be the most natural fit here, but as someone who's never really wanted a three column layout I'm not sure if I'm missing something.

[rhofour]

So, one possible problem with my suggestion is that if we start at 1/3 for the first split, but only have two windows then things would probably seem a bit weird.

Another possibility is a layout which automatically keeps all columns identically sized, but this then loses the ability to resize a column.

A third option, and the very least work, would be to a new horizontal layout where the only difference is that the minor split is horizontal. When you have two windows it would work just like the current horizontal mode. When you add a third then the primary window would take up half the screen and the other two would take up one quarter each. At this point you could then use the usual keys to resize to something close to equal width.

Any thoughts on these options?

[timbertson]

I always imagined that a 3 column layout would have the ability to have a configurable number of windows in each column. So you could have (1,1,1) for three columns, but then (1,1,2) for two full-height winows and then two half-height windows on top of each other in the third column. Or (1,2,2) for a single tall column and then a 2x2 grid in the other two-thirds of the screen. The trouble is, shellshape has a hardcoded notion of main & minor split, so it's not clear how you'd configure this (and how to make sane keybindings).

Amethyst on OSX has "row" and "column" layouts, where you can just split the screen into n rows or columns, one per window. Such a layout would naturally extend to (2,3,4,...) columns, but without the ability to ever have more than one window per column. This could be implemented as @rhofour suggests (with the main and minor axes being the same, unlike the existing layouts), or shellshape could probably be extended to understand layouts with only a single axis.

Would such a row / column layout that work for the people who've expressed interest in a 3 column layout? Or is it important to you that you have 3 columns, and extra windows get stacked within a column instead of adding a new column?

[rhofour]

The biggest problem I see there is the sane keybindings. In addition, this feels like it would make things far more complicated solely to make it needlessly powerful, but maybe I just use my window manager differently. It's also not clear that there's an obvious way to handle (1,1,2) if you have less than four windows.

One way I could see something this powerful working is with some sort of recursive tiling where each tiled area could be retiled. It would complicate things, but it would make everything even more powerful than your suggestions.

Still though, I think the simplest option is best here. If working with the window manager becomes too complicated then you might as well just use the mouse.

[nzjrs]

Thanks for discussing this.

With my monitor (3440x1440) having a three column layout that can't have more than 1 window in the rightmost 2 columns (my understanding of the first suggestion) would be too restrictive as terminals in the rightmost column would be 1440px high, which is often too much for my needs. Therefore the last suggestion (or any implementation where extra windows get stacked within the column) is preferable.

One other feature suggestion. As I primarily work in the centre column, maintaining a key-binding / concept that allowed growing this column by shrinking the columns on either side would be useful.

On 2 January 2017 at 02:22, Richard A Hofer notifications@github.com wrote:

The biggest problem I see there is the sane keybindings. In addition, this feels like it would make things far more complicated solely to make it needlessly powerful, but maybe I just use my window manager differently. It's also not clear that there's an obvious way to handle (1,1,2) if you have less than four windows.

One way I could see something this powerful working is with some sort of recursive tiling where each tiled area could be retiled. It would complicate things, but it would make everything even more powerful than your suggestions.

Still though, I think the simplest option is best here. If working with the window manager becomes too complicated then you might as well just use the mouse.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/timbertson/shellshape/issues/106#issuecomment-269928226, or mute the thread https://github.com/notifications/unsubscribe-auth/AACjo8DqVtaBJtmJRAqIAqHBT4epf9Vdks5rOFFDgaJpZM4AXdOE .

[jluttine]

Wouldn't it be quite straightforward to have arbitrary number of columns and arbitrary number of windows stacked in each column? I think almost all the key bindings etc should work nicely with that. Only resizing would need some reconsidering because currently there is only one boundary to resize so two key bindings suffice, right? Or am I missing some other functionality / key bindings that would need some re-thinking?

Some suggestions:

• Column creation and window moving: Super , and Super . move window to the column on the left/right with respect to the current column of the window. If the window is in the leftmost/rightmost column already, a new column is created and the window moved there. This way you can create as many new columns as you want (as long as you have enough windows) without specifying any fixed number of columns. An empty column would be removed automatically. However, this way you can't create a new column in between two columns. But this would be simple and backward compatible, I think.

• Resizing: Key bindings resize the current column. For the leftmost/rightmost column the current key bindings work as expected as they have only one column boundary (also this is backward compatible). But in columns that are between other columns, one needs to resize both boundaries which would require four key bindings (shrink/enlarge left/right boundary). A simple solution with only two key bindings as currently: enlarge/shrink would affect both boundaries. That is, if enlarge/shrink commands resize the window by X pixels, then both boundaries would be moved by X/2 pixels. Not perfect, but simple and easy to understand and wouldn't require any changes in key bindings.

EDIT: About resizing: in column mode, it seems that stacked window vertical resizing affects the boundary below the current window, not both, so it might be more consistent to resize the rightside boundary of the column (except for the rightmost column, there is only leftside boundary to resize).

[rhofour]

So, it sounds like one thing that would work is adding some new "Custom" layout where you specify rows or columns then how many things go in each row/column. However, this seems like a very narrow solution and I'd rather find something better than this.

I was hoping to make minimal changes to the existing layout/keybindings to make Shellshape powerful enough to handle this. I like the idea of changing Super , and Super .. Right now they just add or remove windows to the main pane. If instead they were repurposed to move the selected window up or down the hierarchy of splits, then combined with a new columns layout like I suggested (where every split is along the same axis) it would be possible to have any number of columns with any number of windows in each. Does this make sense?

The downside to changing those keys is we make things a bit more complicated because now they're context-dependent. This would also probably require making similar changes for the Super h, Super l, Super u and Super i.

[rhofour]

Does this work for people? I don't want to start implementing something a bit complicated if it won't actually solve the problem people are having. If what I said wasn't clear I can quickly make a couple of mocks to better show the idea.

[con-f-use]

It sounds like it would work for me. I'd very much like this.

[neilw4]

I implemented this at https://github.com/neilw4/shellshape. Set the default number of partitions in the settings or press win+shift+> to increment. This works well in my local environment but YMMV.