session: split view and saved terminal workspaces

[Petyok]

Motivation

Termius Focus/Split lets multiple sessions share the viewport. SSHub has multi-tab sessions, detach, broadcast (#3), and dashboard zoom (#18), but only one embedded PTY is visible at a time. Ops workflows (watch logs + edit + second host) want a tiled layout without leaving SSHub.

Proposal

• Split the session area into 2–4 panes (horizontal / vertical), each bound to an open session (or empty → picker).
• Keybinds to split, focus next pane, zoom one pane, close split (session can remain in the strip).
• Optional: named workspaces — saved layout of host → pane arrangement, reopenable from a picker.
• Play nice with the existing session strip and Alt+S session switcher.

Non-goals

• Full tmux/zellij replacement outside SSHub (see dropped tmux / zellij launcher support #10).
• Arbitrary nested splits beyond a small fixed depth in v1 of this feature.

Related

• Dashboard panel focus and tmux-style zoom (z) with Alt+arrows navigation #18 dashboard panel focus/zoom (UX patterns to reuse).
• Broadcast (Broadcast mode: run a command on multiple hosts #3) remains for “same input everywhere”; splits are for “see several at once”.

Priority

High — structural Termius parity for multi-host visibility.

Written by Grok 4.5 (Cursor) on behalf of the maintainer.

[Petyok]

The design core here is not the layout, it is the resize contract, and today it is the opposite of what splits need.

src/lib.rs:176-200 compares the terminal size each tick and, when it changed, resizes every session to the full terminal (s.resize(sz.height, sz.width)). Every PTY is therefore the size of the window, and nothing in the model knows about a region smaller than the screen. Splits invert that: geometry becomes per-pane, and the pane rect — not the terminal — is what the PTY must follow.

What falls out of that, and what the design has to answer before any rendering work:

• Every split, unsplit, focus-zoom and pane-drag is a SIGWINCH to the remote. vim, less, htop and mc redraw on it; some of them badly. A layout that changes size while the user drags is a stream of resizes, so the design needs to say when a resize is committed.
• Detached and background sessions have no pane. Today they still get resized to the terminal. What size does a session in the strip but not on screen have, and does it change when it is put into a pane? Getting this wrong means a remote app that renders for the wrong width until the next keypress.
• vt100 keeps a scrollback per screen size. Shrinking a pane and growing it back is not lossless; the design should say what is expected rather than discover it.
• The motion pass assumes one session fills the area. session_snapshot / dashboard_snapshot and the enter/leave slides are written against a full-area session (src/tui/mod.rs), so animating into a pane needs its own answer or the slides get switched off for splits.

Suggest a spike before the design: two panes, two real PTYs, resize them independently and watch what vim and htop do — hence needs-PoC alongside needs-design. The staging then writes itself, with saved workspaces last since they are just a serialization of whatever the layout model turns out to be.

Written by Claude Opus 5 (Claude Code) on behalf of the maintainer.