You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tracking issue for mouse interaction on the tab bar. The bar started as a passive picture; over several features it is becoming a clickable surface. They all build on the same foundation, so grouping them keeps the shared design (and its traps) in one place.
Shared foundation
Every mouse feature reuses the same two pieces:
Hit-test geometry — LineLayout { tabs, left, right } (src/line.rs:47-51) and TabHit { position, start, width, active } (src/line.rs:24-31) record what each render drew; position_at_column / switch_target_at_column resolve a click column to a target (src/line.rs:111, src/lib.rs:301-310). New click targets extend this recorded geometry rather than overprinting.
Permission model — the default request is exactly ReadApplicationState + ChangeApplicationState (src/lib.rs:291-298). Grants are all-or-nothing and cached, so adding a permission freezes the bar for existing users until they re-grant (zellij#4982). Any new action that needs a third permission must be gated behind an opt-in config flag, the way reorder gates RunActionsAsUser (feat(config): gate RunActionsAsUser behind a reorder flag (default off) so auto-updaters don't freeze #23).
Cross-cutting concerns the children share: row-aware hit-testing (the bar is multi-row, so a click target on one row must not steal clicks from another), width budgeting (new affordances must be reserved in LineLayout, not overprinted), and graceful no-op (clicks on padding / overflow markers / degraded blocks must do nothing rather than misfire).
Overview
Tracking issue for mouse interaction on the tab bar. The bar started as a passive picture; over several features it is becoming a clickable surface. They all build on the same foundation, so grouping them keeps the shared design (and its traps) in one place.
Shared foundation
Every mouse feature reuses the same two pieces:
LineLayout { tabs, left, right }(src/line.rs:47-51) andTabHit { position, start, width, active }(src/line.rs:24-31) record what each render drew;position_at_column/switch_target_at_columnresolve a click column to a target (src/line.rs:111,src/lib.rs:301-310). New click targets extend this recorded geometry rather than overprinting.ReadApplicationState+ChangeApplicationState(src/lib.rs:291-298). Grants are all-or-nothing and cached, so adding a permission freezes the bar for existing users until they re-grant (zellij#4982). Any new action that needs a third permission must be gated behind an opt-in config flag, the wayreordergatesRunActionsAsUser(feat(config): gate RunActionsAsUser behind areorderflag (default off) so auto-updaters don't freeze #23).Cross-cutting concerns the children share: row-aware hit-testing (the bar is multi-row, so a click target on one row must not steal clicks from another), width budgeting (new affordances must be reserved in
LineLayout, not overprinted), and graceful no-op (clicks on padding / overflow markers / degraded blocks must do nothing rather than misfire).Done (foundation)
tab_layoutconsumer)tab) or walk panes across tabs (pane)To do
new_tab()permission first)close_tab_with_index)Notes