| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First pass of the status bar overhaul, in the zjstatus fork plus the layout
that configures it.
margin_left / margin_right: the bar is a full-width pane while every pane above
it is inset by the pane gap, so its ends stuck out past every frame on screen.
The margins are applied by rendering into an inset viewport (inset_state),
which is the same thing click positions are translated by -- so what is drawn
and what is clickable come from one definition. That is the split button's
lesson applied before shipping rather than after.
{new_tab}: a clickable button that opens a tab and focuses it, with no name and
no cwd, i.e. exactly what the `n` binding in TAB mode does. Clicking a tab
already switches to it and double-clicking renames it; making one was the hole
in the strip. Rendering and hit-testing are the same measured string here, so
the button covers exactly the columns it draws.
Both keys are inert when unset, so an unmodified zjstatus config renders
identically.
packaging/checks/status-bar-live.py reads the bar off a real session and
asserts it spans exactly the columns the pane frames span, clicks the + and
expects one more tab, then clicks beside it and expects none. Confirmed by
setting the margins to 0 and watching the span assertion fail: (0, 99) against
the frames' (2, 97).
The check counts painted cells rather than ink, because a bar segment begins
with a padding space inside its coloured pill -- strip the colour and the left
edge reads one column off, which is half the margin being measured.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Double-clicking a tab in the bar switches to it and drops into RenameTab mode,
matching the double-click-to-rename we added for panes in the sl0ppij zellij
fork. Enter commits, Esc cancels, exactly as the rename keybind does.
Widgets are held behind &self and cannot keep click state, so double-click
detection lives centrally in ModuleConfig::handle_mouse_action and is passed
to Widget::process_click as a flag.
THE TRAP, and the reason this is not a two-line change:
handle_mouse_action also runs for Mouse::Release. A single click therefore
arrives as LeftClick followed by Release at the SAME position. Counting
releases would make every single click register as a double click, and
resetting on release would mean a real double click never registers at all,
since the release falls between the two clicks. Only LeftClick participates;
Release neither counts nor resets.
A completed pair is consumed, so a triple click does not fire a second rename.
switch_tab_to() is called before switch_to_input_mode(), because RenameTab acts
on the ACTIVE tab - renaming without switching first would rename the wrong one.
Threshold is 400ms, the same one zellij uses for text-selection double clicks,
so the bar feels consistent with the panes.
Detection is extracted as register_click_for_double_click() so it can be tested
without constructing a ModuleConfig. Tests cover: a real double click, the
release-in-between regression, too-slow clicks, clicks at different positions,
and the triple-click case.
Upstream tests still pass: 25 total (20 upstream + 5 new).
Note: this repo's .cargo/config.toml targets wasm32-wasip1 and runs tests under
wasmtime, which is not installed here. Tests are run with
`cargo test --target x86_64-unknown-linux-gnu` instead.
|
|
|
Squashed import of dj95/zjstatus at 74f36b4 ("chore: bump version to v0.24.0"),
the merge-base our fork was developed against.
Found by the phase-3 smoke test: installing the tarball into a throwaway HOME
and actually starting a session logged
failed to load plugin from disk:
'~/.config/zellij/plugins/zjstatus.wasm' (No such file or directory)
config/layouts/default.kdl replaces zellij's stock tab-bar + status-bar with a
zjstatus bar, so the status bar is load-bearing for the default layout -- and
the .wasm in the live config dir turned out to be a *custom build*, not the
upstream release. Dropping it as "a third-party blob no longer referenced" (see
the config snapshot commit) was wrong: it was referenced from the layouts, which
that commit did not check.
|