also looking at this
feat: add Linux and Windows named-window routing
#325
29 files
+2250
-200
Review threads live on the whole diff, not on one commit, so none are shown here - a thread's line means something in the branch's final form, and painting it into an intermediate step would put it on code it is not about.
| @@ -158,6 +158,9 @@ Currently implemented foundations (experimental): | ||
| 158 | 158 | - ✅ Named runtime windows, addressed controls, and scoped window events (GUI smoke in CI) |
| 159 | 159 | - �� Other bridge parity and advanced window behavior remain incomplete |
| 160 | 160 | |
| 161 | The Xvfb smoke covers named create, addressed replies, close, and reopen; it | |
| 162 | does not establish full desktop bridge parity for a particular application. | |
| 163 | ||
| 161 | 164 | ### Known Limitations |
| 162 | 165 | |
| 163 | 166 | - **Transparency**: Requires compositor (e.g., Picom, Compton) |
| @@ -251,6 +254,9 @@ Currently implemented foundations (experimental): | ||
| 251 | 254 | - ✅ Named runtime windows, addressed controls, and scoped window events (WebView2 GUI smoke in CI) |
| 252 | 255 | - �� Other bridge parity and advanced window behavior remain incomplete |
| 253 | 256 | |
| 257 | The native WebView2 smoke also exercises concurrent child creation and cleanup; | |
| 258 | it does not establish full desktop bridge parity for a particular application. | |
| 259 | ||
| 254 | 260 | ### Known Limitations |
| 255 | 261 | |
| 256 | 262 | - **WebView2 Required**: End users must have WebView2 Runtime installed; release archives include the app-local loader DLL |
| @@ -75,9 +75,10 @@ back to whichever window was created most recently: | ||
| 75 | 75 | - The local scroll monitor is installed once, but reads the event's `NSWindow`, |
| 76 | 76 | advances only that window's accumulator and emits only to its webview. |
| 77 | 77 | |
| 78 | `close()` preserves these resources and the SDK's native-event subscriptions | |
| 79 | so the same page can reopen with its DOM and JavaScript state intact, including | |
| 80 | when the primary window is reopened by the Dock rather than `createWindow()`. | |
| 78 | On macOS, `close()` preserves these resources and the SDK's native-event | |
| 79 | subscriptions so the same page can reopen with its DOM and JavaScript state | |
| 80 | intact, including when the primary window is reopened by the Dock rather than | |
| 81 | `createWindow()`. | |
| 81 | 82 | `destroy()` removes the named registry entry, Native UI graph, gesture and |
| 82 | 83 | material slots, recovery state, event ownership and retained AppKit objects |
| 83 | 84 | before releasing the window and detaching the SDK's DOM listeners. |
| @@ -139,9 +140,9 @@ The next multi-window milestone needs product decisions in addition to code: | ||
| 139 | 140 | 4. Finish advanced Linux/Windows window actions and clarify which are portable |
| 140 | 141 | versus platform-specific, without conflating close semantics: macOS retains |
| 141 | 142 | a closed page, while Linux and Windows release it. |
| 142 | 5. Complete platform-native integration coverage. Linux WebKitGTK runs under | |
| 143 | Xvfb in CI; Windows currently has a cross-build but still needs a real | |
| 144 | WebView2 lifecycle smoke on a capable Windows runner. | |
| 143 | 5. Expand platform-native integration beyond the current named-window lifecycle | |
| 144 | smokes. CI runs Linux WebKitGTK under Xvfb and Windows WebView2 on a native | |
| 145 | runner, but advanced actions and packaged-app behavior still need coverage. | |
| 145 | 146 | |
| 146 | 147 | ## Review checklist |
| 147 | 148 | |
| @@ -151,6 +152,8 @@ For every new bridge or callback that touches a window, verify: | ||
| 151 | 152 | - An explicit window ID is resolved through the registry and unknown IDs fail. |
| 152 | 153 | - An asynchronous reply retains both its target and its requesting webview. |
| 153 | 154 | - A delayed control callback stores its owner on the control/delegate instance. |
| 154 | - Ordinary close preserves state; permanent destroy forgets it exactly once. | |
| 155 | - On macOS, ordinary close retains the page and permanent destroy forgets it | |
| 156 | exactly once. On Linux and Windows, close and destroy both release the native | |
| 157 | window/webview; a later open of the same name creates a fresh native page. | |
| 155 | 158 | - A process-global event sink is documented as primary, broadcast or |
| 156 | 159 | subscriber-owned rather than inheriting accidental last-window behavior. |
| @@ -483,9 +483,10 @@ by `on`, such as `stopWatching()` above, when the listener is no longer needed. | ||
| 483 | 483 | On macOS, closing a window keeps its native page alive so reopening can |
| 484 | 484 | restore its DOM and JavaScript state. On Linux and Windows, closing releases |
| 485 | 485 | the native window and webview; reopening the same ID creates a fresh page |
| 486 | behind the same stable SDK handle. Call `destroy()` to permanently release a | |
| 487 | runtime-created window and its event subscriptions. The unnamed primary window | |
| 488 | cannot be force-destroyed through this API. CI exercises Linux | |
| 486 | behind the same stable SDK handle. `destroy()` releases a named window's native | |
| 487 | resources and detaches its SDK DOM listeners. A later `createWindow()` with the | |
| 488 | same ID reuses the typed handle and reattaches those listeners. The unnamed | |
| 489 | primary window cannot be force-destroyed through this API. CI exercises Linux | |
| 489 | 490 | create/close/reopen under Xvfb and the equivalent Windows WebView2 path, |
| 490 | 491 | including concurrent child creation and stale-handle cleanup. |
| 491 | 492 | Modal/parent semantics are not part of the runtime-created-window contract yet. |