a sl0p.foo repository https://git.sl0p.foo/sl0ppi.git/atom/sl0pstatus/src?h=main 2026-08-13T18:54:29Z 2026-08-13T18:54:29Z user user@clank 2026-08-13T18:54:29Z urn:sha1:e220bb7cb784140ba5c9cc1fe59b71fdb9dbf4b9 Given three rows the bar now draws the same rounded box the panes do, so the bottom of the screen reads as one more pane instead of a strip of text under them. Given one row it stays the line it always was, which is what a terminal narrow enough to collapse the layout should spend on chrome. The height is the LAYOUT's decision, because a plugin cannot resize its own pane: - default.kdl defines the bar as a pane_template `sl0pbar` and places it at size=3; - default.swap.kdl defines tab_template "mobile" placing the same template at size=1, and the `stacked` swap layout -- what responsive_layout collapses to below responsive_min_cols -- uses it. That reuse works because zellij parses a layout and its .swap.kdl with the same parser, on purpose, "so that we can reuse assets (eg. pane and tab templates)". Otherwise the collapsed template would have to duplicate the whole 100-line zjstatus configuration, and the two would drift within a week. ModuleConfig::viewport is the one definition of where the content line lives: three rows or more and it is framed, fewer and it is not, plus the column the content starts at. Rendering and click routing both read it, so the frame moves the drawing and the hit-testing together -- a click on the new border hits nothing rather than the widget it sits above. Clicks now check the LINE too, which a single-line bar never had to. status-bar-live.py grew the other half of the feature: the borders must span exactly the columns the pane frames span with rounded corners at their ends, a click on the border must not make a tab, and after shrinking the terminal below the responsive threshold the bar must be one line with no box -- with its button still working. The collapse is real: the bar lands on the last row, which only happens if the swap layout actually switched. One test bug worth naming: locating the button with str::find gave a BYTE offset, and the box glyphs are three bytes each, so the click landed two columns right of the thing it found. Same trap the pane frame tests document. 2026-08-13T18:36:45Z user user@clank 2026-08-13T18:36:45Z urn:sha1:91f40dccd9def02d147ea41615f7bc159cb306a6 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. 2026-08-12T18:41:52Z user user@clank 2026-08-08T21:54:38Z urn:sha1:f075ce0bd2ac29168e27596ab32abdfb6b2813ec 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. 2026-08-12T18:41:52Z user user@clank 2026-08-12T18:41:52Z urn:sha1:dd1c0b2abb3734177fde75e88607dbe16f6357e9 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.