aboutsummaryrefslogtreecommitdiffstats
path: root/cli/src
diff options
context:
space:
mode:
authoruser <user@clank>2026-08-13 14:04:23 +0200
committeruser <user@clank>2026-08-13 14:04:23 +0200
commit8e93e00e2c8f5692b6fbc200d989646bd088ddad (patch)
tree9bc363dabc2cbd6207900d2eaecf65f4d3b6ae73 /cli/src
parentdocs: record the responsive fix and how to re-verify it (diff)
downloadsl0ppi-8e93e00e2c8f5692b6fbc200d989646bd088ddad.tar.gz
sl0ppi-8e93e00e2c8f5692b6fbc200d989646bd088ddad.tar.xz
sl0ppi-8e93e00e2c8f5692b6fbc200d989646bd088ddad.zip
sl0p: a mouse affordance for splitting a pane
Switching panes, switching tabs, renaming, reordering and resizing all have a mouse path in this fork. Spawning a pane did not: it was keyboard-only. A `+` now appears at the right end of a pane's title line while the pointer is over that pane, and clicking it splits the pane. Hover-driven rather than always drawn, for the same reason the resize hint and the status bar button highlight are: a permanent `+` on every frame is noise, and the pointer being there is exactly when the button is useful. render ui/pane_boundaries_frame.rs::render_split_button hit tab/mouse_handler.rs::intercept_split_button_click shared split_button_columns(), so what is clickable is what is visible The button sits immediately left of the top-right corner and the existing scroll and pin indications get the room that is left. That ordering is deliberate: a fixed position relative to the pane's right edge is one the mouse handler can hit-test directly, instead of re-deriving the whole title layout the way `status_bar_button_at` has to. The clicked pane is focused first, then the split is requested exactly as a keybinding would (`PtyInstruction::SpawnTerminal` with `NoPreference`), so mouse and keyboard produce the same arrangement and the split lands on the pane whose button was clicked rather than whichever pane happened to be focused. Not drawn on floating panes: their PIN control owns that corner and is hit-tested by its drawn position, so anything to its right silently moves it out from under the pointer. Caught by test_ctrl_click_on_floating_pin_button_toggles_pin, which stopped pinning. Verified on the test box by injecting real SGR mouse events into an attached client's pty at 160x45: click on the button 1 -> 2 panes click on the title 1 -> 1 click mid-frame 1 -> 1 Two hover snapshots updated, and only those two: the `+` on the hovered pane (including an unfocused one -- splitting a pane you are not in is useful). zellij-server 1502 pass, zellij-utils 473 pass.
Diffstat (limited to 'cli/src')
0 files changed, 0 insertions, 0 deletions