Module app 

The root component: hosts the panel as one or more dock windows — a left dock, a right dock, or both — each containing its own stack of split panes, and applies single-instance launch requests.

Dock model ────────── [Dock] is one layer-shell window anchored to one screen edge. It owns a vertical stack of Panes. A Pane is a top bar (hamburger menu + editable path entry), an optional filter row, and its own Tree component. Panes have globally stable ids (never reused after close) so toolbar/tree messages survive dock rebuilds and pane removals.

The first dock is the primary dock: its window is the relm4 root window (rendered by view!), its container is App::pane_container. Additional docks are created on demand when a launch request names a side not present yet; they are ordinary gtk::Windows built imperatively.

Split-pane layout within a dock ─────────────────────────────── The GTK widget tree is rebuilt from scratch when a dock’s pane count changes. Panes are nested with gtk::Paned:

panes = [A, B, C] widget tree = Box { Paned { A, Paned { B, C } } }

Each pane is a vertical Box { toolbar, filter-bar, tree }. The tree widget’s vexpand is set to true so each half fills its allocation. Every pane has its own filter bar (hidden until requested from that pane’s top-bar menu); it applies only to that pane’s tree.

Launch requests ─────────────── A second tree-space invocation is forwarded over the instance socket (see crate::ipc) and arrives as AppMsg::LaunchRequest:

• no path → show/hide the whole panel (toggle), or with --side X ensure a dock exists on X and show it
• with path(s) → add a pane for each path (never a duplicate of an already-open directory), then show the panel

Structs

App

Root state.

AppInit

The init payload: the parsed invocation plus the instance socket, if this process became the single server.

AppWidgets

Pane

One split view inside a dock: its own top bar above its own body.

VisibilityPlan

The resolved effect of a VisibilityIntent: which sides should be shown afterwards, and whether a missing dock should be created to satisfy it.

Enums

AppMsg

Messages handled by the app itself.

VisibilityIntent

What an invocation (or the hamburger “Collapse”) wants to do to dock visibility. Pure data, so the show/hide rules can be unit-tested without a display (see the visibility tests below).

Functions

resolve_visibility

Resolve intent against the dock sides that currently exist and the sides currently shown. show/hide name the sides to act on; create names a side whose dock must be created first.