2 Commits

Author	SHA1	Message	Date
topkoa	188bdaa837	feat(panes)!: move the real element, instead of rebuilding it ... The first cut of this got the model wrong. A pane was a SECOND implementation of the plugin's panel — its own sliders, its own styling, driven over a cross-realm bridge (ctx, a state store, capability RPC, mirrorGlobal, a stream sampler). Popping out gave you something that resembled the panel you popped, and every feature it did not reimplement (presets, tabs, EQ, language) was simply gone. What a user wants from "pop this out" is the thing they popped out. So: MOVE THE REAL ELEMENT. Same-origin windows can adopt each other's nodes, and an adopted node keeps its event listeners and its closures. The panel goes on running the plugin's own code, against the plugin's own state, in the plugin's own realm — it is merely being DISPLAYED in another window. Copy the app's stylesheets into that window and it looks identical too, because it is identical. The plugin's side collapses to two lines: feedBack.panes.register({ id, title, element: () => panelEl }); feedBack.panes.attachChip(panelEl, id); and everything comes along: the CSS, the listeners, the presets, the state. Nothing to keep in step, because there is no second copy. Deleted, all of it now pointless: pane-bridge (ctx + transports), pane-hub (the cross-realm server), pane-runtime (the pane realm's boot), pane-streams (the rAF sampler that existed because an AnalyserNode can't cross a window), pane-mirror (mirrorGlobal), pane-plugins + the manifest `panes[]` key and its server-side validation, panes.state(), and both built-in demo panes. ~1200 lines. None of it was wrong — it was all correct machinery for the wrong problem. Consequences worth knowing: - The window MUST be opened by the renderer with window.open(), not by the desktop's main process: a window we did not open gives this realm no handle to its document, and without the handle there is nothing to adopt into. Electron turns the same-origin window.open() into a real BrowserWindow anyway (setWindowOpenHandler → 'allow'), so we get the OS window AND the live DOM link. The desktop side finds it by frame name. - `.fb-paned` neutralises PLACEMENT only (position/inset/width/z-index/shadow). A plugin panel is nearly always a fixed overlay pinned to a corner of the app; alone in a 380px window that positioning is nonsense. Colours, borders, padding, fonts and the panel's own internal layout are untouched — the whole promise is that what you popped out is what you get. - The element is returned to its EXACT home on dock: same parent, same position among its siblings. - The plugin's code still runs in the main window. So a document.body .appendChild() inside a panel (a tooltip, a popover) lands in the main window, not the pane — anchor to the panel instead. And a continuously animating panel may run slowly while the main window is backgrounded, since its rAF lives there. Both documented. Signed-off-by: topkoa <topkoa@gmail.com>	2026-07-12 18:12:46 -04:00
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