2 Commits

Include renames

Author	SHA1	Message	Date
topkoa	fefb9051a4	feat(panes): pop-out windows — the pane realm, hub, and remote transport ... A pane can now leave the main window entirely. Same `mount(root, ctx)`, same file, different JS realm — which is what the ctx-only contract in the previous commit was for. ## A purpose-built document, not the app shell with a flag on it `GET /pane` serves static/panes/pane.html: the bridge, the runtime, and the pane's own script. No highway, no library, no v3 shell, no <audio>, no Tailwind. The splitscreen follower takes the other road — it reloads the whole app at `/?ssFollower=1` and hides what it doesn't want — and pays for it with an anti-flash block that must run before any script parses (index.html), bail-outs in app.js and shell.js, and ~40 lines of CSS hiding core elements by id. It loads the entire app to throw it away. A pane window has nothing to throw away, so it boots in milliseconds and there is nothing to flash. The cost is that `window.feedBack` in a pane realm is a deliberate, documented SUBSET. The runtime installs exactly what a pane is promised — `panes.register`, and the no-op chip/dock calls a shared script may make at load — so a pane reaching for something it was never given fails loudly at authoring time instead of subtly at runtime. ## The channel BroadcastChannel('feedback-panes'), same origin. This works only because Electron's setWindowOpenHandler returns `action: 'allow'` for same-origin URLs: `deny` would push the window to the system browser, a different Chromium instance, where BroadcastChannel cannot reach it and the pane would silently never sync. That flag is load-bearing. hello -> snapshot resync-on-open, always. The snapshot is the only way the pane realm learns anything. state main is authoritative. A pane's write is a REQUEST; main applies it and echoes to every realm, so a losing write self-corrects instead of splitting brain. rpc / rpc:reply ctx.call() -> the capability bus, with a 10s deadline. Without one, a main window that died mid-call leaves the pane's promise pending forever. event allowlisted bus events, JSON-safe. A CustomEvent carrying a DOM node (highway:canvas-replaced does) would throw on postMessage and take the channel down for everyone, so detail is round-tripped through JSON. stream one coalesced message per pane per frame, OVERWRITING anything not yet flushed. Queueing would build a backlog: Chromium throttles a backgrounded window, and the main window is exactly what's backgrounded while the user looks at the pane. sub / unsub refcounts the main-realm sampler. bye both directions. ## The follower clock The pane extrapolates between broadcasts: anchor + observedRate * elapsed, capped at 2s. observedRate is learned from the broadcasts themselves (dt/dwall) so it tracks the speed slider without being told about it, and seeks/pauses are excluded from the fit — a jump is not a tempo. Capping it means a dead main window decays into a frozen clock rather than one that confidently runs away. This is splitscreen's hard-won trick, generalized: panes just call ctx.playhead(). ## Failure modes, all of them - Main window closes -> `bye {main-closed}` and the pane says so plainly, rather than showing a frozen playhead that looks live. The host also closes its windows outright; a pane that cannot be fed should not be on screen. - Pane window X'd or crashed -> a `closed` poll reaps it (a crashed renderer never sends `bye`), the pane closes, and the chip's dialog comes back. Without this the user's dialog stays hidden with no way back. - Popup blocked -> a toast, and we bail BEFORE the manager records anything, so the caller's dialog stays exactly where it was. - Nobody answers `hello` in 5s -> the window says so instead of spinning. - A pane with no `script` is a closure in this realm and cannot honestly cross a window boundary. The window host declines it (canHost) and the router falls back to the dock. - A browser blocks window.open() outside a user gesture, so a popped-out pane cannot be auto-restored on page load — it would only ever produce a "blocked" toast. Such a pane comes back in the DOCK, and the chip pops it out again on the next click. (autoRestore: false. The desktop host will set it true.) Hosts may now declare `remote: true`, meaning the pane's mount() runs in another realm: the manager then owns only the authoritative state store and never calls mount() itself. That is the seam the Electron BrowserWindow + tray host drops into next, with no change here. Verified: popped Now Playing and Mixer into real windows. The pane realm has no window.highway, no capability bus and no <audio>, yet the Mixer renders its faders via ctx.call('audio-mix','list-faders') across the channel — and dragging that fader IN THE PANE WINDOW moved the main window's song volume to 55 and persisted it. Closing the pane window un-hid the mixer dialog, removed the stub and restored the chip, while the other pane window stayed open. Signed-off-by: topkoa <topkoa@gmail.com>	2026-07-12 17:03:21 -04:00
topkoa	e5cbea2e9f	feat(panes): core detachable pane system + pop-out chip ... The option-heavy player UIs (mixer, camera director, viz, audio routing) all live in the rail popovers, which are exclusive: openPopFor() closes the last one before opening the next. You cannot watch the mixer while riding the camera, and both vanish the moment you look at the highway. Add `window.feedBack.panes` — a core registry for live UI that is authored once as `mount(root, ctx)` and hosted anywhere. Panes are non-exclusive, and they survive song switches structurally: the dock is a body child outside every .screen, so the per-song teardown never sees it. The adoption cost for a plugin is two calls: feedBack.panes.register({ id, title, icon, mount, unmount }); feedBack.panes.attachChip(myExistingDialogEl, id); attachChip injects THE standard pop-out chip. Clicking it opens the pane and hides the plugin's dialog, leaving a stub to bring it back. Core owns the hide/restore, so every plugin's pop-out looks and behaves the same — which is the point. It hides via a dedicated .fb-pane-detached class, not .hidden/[hidden], because the dialogs we attach to already toggle those. Everything a pane may touch arrives through `ctx` — never a global. That is what will let the same mount() run inside a pop-out window, a separate JS realm with no window.feedBack, no window.highway and no audio graph: ctx.call(domain, cmd, payload) -> the capability bus ctx.on(event, fn) -> the feedBack bus (allowlisted) ctx.subscribe(stream, fn) -> playhead / meters ctx.state.get/set -> persisted, main realm is the only writer ctx.playhead(), ctx.song(), ctx.toast(), ctx.close() ctx tracks every subscription it hands out and drops them on unmount, so a pane cannot leak listeners across a dock/undock cycle. Streams exist because an AnalyserNode cannot cross a window boundary: levels are reduced to numbers in the realm that owns the audio graph. One shared rAF loop, refcounted against live subscriptions, dirty-checked before fan-out, and stopped dead when the last pane closes. Hosts register themselves with the manager rather than being imported by it — the dock lands at priority 0 (the floor, always available), so the OS pane window can drop in later without this code changing. Ships two built-in panes: Now Playing (the reference pane — reads the bus, a stream, and levels, and touches no globals) and Mixer (the same faders as the rail, via ctx.call('audio-mix', ...), with the chip attached to the real #mixer-control). Plus a "Panes" rail popover to open panes that have no dialog of their own; the system tray will mirror that list. Note the dock sits at z-index 110, not on the docs/plugin-v3-ui.md ladder (transport 20, rail 30, popovers 40) — those live INSIDE #player's stacking context, and #player is itself fixed at z-index 100. A dock below 100 is invisible on the one screen panes exist for. Body-level ladder: #player 100 < dock 110 < toasts 120 < modals 200. Pop-out windows, the system tray, manifest-declared panes and mirrorGlobal (the window.__h3dCamCtl proxy the camera director needs) follow. Signed-off-by: topkoa <topkoa@gmail.com>	2026-07-12 16:54:15 -04:00