Canvas layouting: tile multiple canvases on one screen (New Column / New Row)

[Weegy]

Problem

Today the Tier-1 host app renders one canvas at a time — a single surface tree fills the workspace. The multi-canvas workspace (#9) lets users keep several canvases and switch between them, but there is no way to see more than one canvas on the same screen. For comparison-style work (e.g. two SEO reports side by side, a query result next to a chart, a data table beside its detail view) the user has to flip back and forth.

Goal

Add layouting tools so a user can compose multiple canvases into one screen as a resizable grid, with two primitive operations:

• New Column — split the current workspace (or the focused pane) horizontally and host another canvas to the right.
• New Row — split vertically and host another canvas below.

Each pane is an independent canvas: its own session, its own live surface stream, its own turns. The result is a tiling grid of canvases the user arranges to taste.

Proposed UX

• A workspace-level affordance (header/toolbar or a per-pane control) offering New Column / New Row.
• Adding a pane prompts which canvas to load into it — a new (empty) canvas or one picked from the canvas library (Surface materialised UIs: canvas library / Omadia Graph integration with user assignments #12).
• Panes are resizable (drag the divider) and closable (closing the last pane returns to the single-canvas view).
• The active/focused pane is where new turns and beam input are directed; focus is visually indicated.
• The grid layout (which canvases, their positions and sizes) persists across restarts in the host settings/session store, like the single canvas session does today.

Technical notes

• The host already owns a per-canvas CanvasSocket (handshake → canvasSessionId → surface stream). A multi-pane workspace = N independent sockets/sessions, one per pane — no protocol change required for v1; it is a host-app composition concern.
• The renderer needs a workspace grid container above today's single-canvas root (App.tsx / PrimitiveNode render the tree per pane unchanged). A split model (binary splits → Column/Row, or a CSS grid of panes) drives the layout.
• Layout state: extend the settings/session store with a workspace descriptor (tree of splits → leaf = { canvasSessionId, serverUrl }, plus split ratios).
• Reuses existing reconnect/handshake/resync per pane; each pane keeps its own revision/seq counters.

Acceptance criteria

• User can add a canvas to the right (New Column) and below (New Row) of an existing one.
• Each pane runs an independent canvas (own session, own live turns) with no cross-talk.
• Panes are resizable and closable; closing the last pane restores the single-canvas view.
• The active pane receives turns/beam input; focus is visible.
• The grid layout persists across app restarts.

Related

• feat(app): Omadia UI canvas host — 24-primitive renderer, Lume v0.4, multi-canvas workspace, release pipeline #9 — Omadia UI canvas host / multi-canvas workspace (this extends the workspace from switch-between to tile-together)
• Surface materialised UIs: canvas library / Omadia Graph integration with user assignments #12 — Surface materialised UIs: canvas library (source for picking a canvas into a new pane)

[Weegy]

Implemented in PR #9 (client d329ec4 + 7affc60; no Tier-2 change needed — host-app composition as scoped):

• Binary split tree drives the workspace: leaf = one canvas slot, split = two children as columns (New Column, side by side) or rows (New Row, stacked) with a clamped, drag-resizable ratio (pointer-captured divider). The layout persists client-side and is pruned at load when a canvas no longer exists (a vanished leaf collapses its split).
• Every pane is an independent canvas on the existing one-socket-per-slot architecture: own session, own surface stream, own turns — switching or splitting never interrupts an in-flight stream. The focused pane (lit ring, §3.2 glow) is where prompts, beam input, and typed actions go; clicking anywhere in a pane focuses it. Pane title pulses while its turn is building.
• New-pane chooser: a fresh split shows two options in place — an "Ask Omadia" spotlight (prompt starts a new canvas) or adopt an existing canvas, rendered with the same live mini-preview cards as the library (Surface materialised UIs: canvas library / Omadia Graph integration with user assignments #12). Adopting discards the placeholder slot cleanly (socket, refs, registry entry — no ghost canvases).
• Close collapses the pane into its sibling (the canvas itself stays in the sidebar and keeps streaming); the last pane cannot close — single-canvas view is the degenerate one-leaf layout, so the classic experience is unchanged. Canvas delete (Delete canvases from the Omadia UI (per-user removal, full delete on last reference) #8) prunes the layout too.
• Sidebar/library selection is layout-aware: picking a canvas already on screen focuses its pane; otherwise it loads into the focused pane.

Acceptance criteria: New Column/New Row ✓ · independent panes without cross-talk ✓ (verified live: split mid-session, both panes streaming) · resizable + closable with single-canvas fallback ✓ · focused pane receives turns with visible focus ✓ · layout persists across restarts ✓.

Verified end-to-end against the live kernel: start → workspace restores → New Column → chooser (8 candidate cards + prompt) → adopt → two canvases tiled ("Monatsumsatz 2025" | "SEO-Check") → close → clean collapse. 74 renderer/node tests green.

Also in this push: the post-sign-in redial is hardened (a rejected teardown no longer drops the reconnect continuation) plus a 12 s safety valve — the sign-in pane can no longer dead-lock in "Signing in".