diff options
| author | user <user@clank> | 2026-08-12 15:50:04 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-12 15:50:04 +0200 |
| commit | 266147d1d5ecadafda6a4893a60019c80f3c2c85 (patch) | |
| tree | 761be672fca76155d407ffda8be4a0c99033fc62 /zellij-integration-tests/tests/snapshots/resize__resize_decrease_left.snap | |
| parent | sl0p: document the pane status bar protocol (diff) | |
| download | sl0ppij-266147d1d5ecadafda6a4893a60019c80f3c2c85.tar.gz sl0ppij-266147d1d5ecadafda6a4893a60019c80f3c2c85.tar.xz sl0ppij-266147d1d5ecadafda6a4893a60019c80f3c2c85.zip | |
sl0p: highlight the status bar button under the pointer
A click target with no hover feedback gives you no way to tell what you are about
to hit, which matters more here than elsewhere because the buttons sit in a frame
row that is only one cell tall.
The hovered button is inverted rather than merely recoloured: swapping
fore/background reads regardless of which colours a theme uses, and makes "the
pointer is on THIS one" unmistakable next to its unhovered neighbours.
Tracked per client, because hover belongs to a pointer rather than to a pane --
with two users attached, one pointer must not light up the other's button. Stored
on the pane keyed by client id, which the frame renderer already has.
Updated before the action dispatch rather than in the hover action, because
motion over the ACTIVE pane is dispatched as SendToTerminal, not UpdateHover --
and the pane you are about to click a button in is usually the one you are
already in. Every other pane's hover for that client is cleared on each motion,
so moving between panes cannot leave a button lit behind.
Diffstat (limited to 'zellij-integration-tests/tests/snapshots/resize__resize_decrease_left.snap')
0 files changed, 0 insertions, 0 deletions
