diff options
| author | user <user@clank> | 2026-08-13 14:46:03 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-13 14:46:03 +0200 |
| commit | a4a5e7b8287ef4e8421f4a7e9c659ac14eebafed (patch) | |
| tree | 9abd49fdf0db30120e9a62cf1834cc959dba7fbf /cli/src | |
| parent | release: 0.1.7 (diff) | |
| download | sl0ppi-a4a5e7b8287ef4e8421f4a7e9c659ac14eebafed.tar.gz sl0ppi-a4a5e7b8287ef4e8421f4a7e9c659ac14eebafed.tar.xz sl0ppi-a4a5e7b8287ef4e8421f4a7e9c659ac14eebafed.zip | |
sl0p: draw the split button always, not only on hover
The hover-gated version did not work. `mouse_is_hovering_over_pane` never became
true in a live session, so the `+` was invisible while its hit-test -- which is
geometric and never consulted hover -- kept working. Clickable but invisible is
the worst of both, and it is exactly the failure the shared
`split_button_columns()` was supposed to prevent: that guarantees render and
hit-test agree on WHERE, not on WHETHER.
Reported as "I hover over panes but don't see a +". My end-to-end test had
proved the click, not the button, and the passing snapshots only proved the
renderer works when the flag is set.
Why the flag is false live is still open and is written into the code comment:
the plumbing from `mouse_hover_pane_id` through `FrameParams` reads correctly,
and the config that reproduces it sets both `advanced_mouse_actions` and
`mouse_hover_effects`. Re-gate on hover only once that is understood AND shown
on a real session rather than in a snapshot.
265 snapshots updated: every pane frame now carries the button. 233 are
mechanically provable as button-only (the ` + ` replaces three horizontal glyphs
before a corner); the remaining 32 differ only by a header line offset in the
comparison, with the same substitution underneath.
Diffstat (limited to 'cli/src')
0 files changed, 0 insertions, 0 deletions
