Change Splits feature to more closely match COSMIC UX

[WatchMkr]

Splits feature

• Single-split by default
  • Vertical split until window resized to single column then horizontal (this is for app responsiveness by default)
  • Activated by
  • Ctrl + ;
  • View menu > Split
  • Shortcuts
  • Ctrl + ~ toggles between the two splits
  • Ctrl+Shift+Arrows or Ctrl+Shift+HJKL moves between splits
  • Maximize split Ctrl+Shift+M

Multi-Split

• Activated in Settings
  • Each Ctrl + ; splits the focused pane in half opposite the longest side (same as tiling)
  • Ctrl + ~ moves between the last two panes with focus
  • Ctrl+Shift+Arrows or Ctrl+Shift+HJKL moves between panes
  • Show thin accent around the currently focused split. Can be disabled in Settings. (already present when hovering for resize.)

Change View > Split menu and Context menu to match the feature changes

[snaggen]

While I understand the idea behind this, to get a more consistent and familiar UI, I really think this design might be slightly miss the target. The reason I think that is that this might be a case where the Specific case is quite different from the General case, so what works for the general desktop might not be as useful for the cosmic terminal.

In general, most applications works pretty well in portrait mode, editors, pdf readers, web browsers, mail, word processors and so on. Screens are landscape, so vertical split is a good default assumption. However, terminals are an historical artifact, with a historical preference of width 80 and height 24 characters which is landscape. Most command output and application have this deep down in the design, causing command output and cli application to quickly become unusable when less then 80 width. However, here is the asymmetry, while the width is important, the height isn't. Most commands can be run and used with only 10 lines height, since we have a scroll history and can scroll upwards. So, for terminals, a horizontal split is much more forgiving, then a vertical split.

Also, terminals are power user tools. When a terminal user preform a split, it is done with a purpose and a clear thought. If that is not doing what the user expects, then that is going to be an annoyance. Unfortunately, due to the nature of the terminal, it is hard for the system to predict if a vertical split is preferred (which might be the case if an editor is to be used) or a horizontal split is better (if a cli prompt for compiling, and similar is to be used.).

So, what is my point with all this. Well both these automatic split use cases may breakdown pretty quick, and it is almost impossible to do a qualified guess of the "correct" split.

Single-split will be splitting the window in the direction where terminals are least forgiving. Since screens mostly are landscape, it will split well one or two times (on a 32" 16:9 screen I can't have 4 terminals next to each other and still have 80 columns, which means that it will only split once before getting unusable). But having a hard limit to start splitting horizontal if next split would cause the terminal to be less than 80 wide, could be somewhat useful, but will still not be the "correct" split in may cases (since the correct split is very different if the user plans to use it as a command prompt or run a TUI application).

Splitting the longest edge will most likely break down to be unusable really fast since the terminal will become to narrow, and will most likely almost never do what the user wants.

So, I suggest to keep the manual split as an option at least, and to test the automatic splits on some power users before making them default.

The only downside of manual splits are one extra keyboard short cut, and an inconsistency with the general desktop splitting. However, a terminal as an application is not very consistent with the general applications to begin with, so that should not be a huge issue. And having to select either vertical or horizontal splits, is not a huge issue since the user is already having the hands on the keyboard, with a clear intent of what to do.