@bobfrankston/msgapidefs 0.1.37 → 0.1.38

package/README.md

@@ -75,13 +75,18 @@ msger + msga cover every platform, so the Electron host has no platform to itsel
 **Do not do feature-parity work on msgview.** New features land in msger (and msga
 where it makes sense); msgview catches up only on demand, if a real need appears.
 
-What Electron alone could still do, and why it isn't a reason to keep syncing it:
-
-- **Unpacked Chrome extensions** (`-extension`) — wry has no extension API and
-  WebKitGTK has none at all. If Chrome features are needed, use Chrome directly.
-- **`-render` off Windows** — msger's capture goes through WebView2 DevTools, so it
-  is Windows-only; msgview's `capturePage()` works everywhere. Portable to
-  WebKitGTK's snapshot API if it ever matters.
+**As of 2026-08-01 msgview has no capability msger lacks.** The two things that
+used to be Electron-only are both settled:
+
+- **Unpacked Chrome extensions** (`-extension`) — not how add-ins are done here.
+  **`window.msgapi` (this package) plus injected init scripts is the add-in
+  mechanism**: `initScript` / `initScriptPath` inject app JS into every document
+  before page scripts run, with the full msgapi surface available — host-native,
+  works in msger and msga, no Chromium required. If something genuinely needs
+  Chrome extension APIs, run it in Chrome.
+- **`-render` off Windows** — ported. msger now captures on Linux/Pi through
+  WebKitGTK's snapshot API (see the render row above), verified on a Pi 5 for both
+  PNG and JPEG output.
 
 Engine currency is *not* a reason: a feature probe on Pi 5 / WebKitGTK 2.50.6
 (2026-07-31) passed 23 of 24 modern checks — `:has()`, CSS nesting, container
@@ -147,9 +152,9 @@ nothing about capability.
 | `http.fetch()` | ✅ | ✅ | ✅ | Native HTTP — bypasses CORS/mixed-content |
 | **Host Launcher Features** | | | | *Not part of `window.msgapi`; CLI / launcher-side* |
 | Markdown rendering (`.md`/`.markdown` auto-render) | ✅ | ✅ | ❌ | Local `file://` URL → rendered HTML via `msgcommon/markdown` (marked + light/dark CSS). msga could match it in `MainPage.xaml.cs` URL interception — not done yet. |
-| Unpacked Chrome extension loading (`-extension <dir>`) | ✅ | ❌ | ❌ | msgview-only via `session.extensions.loadExtension`. wry has no public extension API; WebKitGTK has none at all. msga would need a separate Android/WebView2 plumbing — not planned. |
+| Unpacked Chrome extension loading (`-extension <dir>`) | ✅ | ❌ | ❌ | msgview-only via `session.extensions.loadExtension`. wry has no public extension API; WebKitGTK has none at all. **Not the add-in mechanism here** — app add-ins are `window.msgapi` + injected init scripts (`initScript` / `initScriptPath`), which work in msger and msga without Chromium. Chrome-extension-specific needs go to Chrome. |
 | Headless mode (`-noshow` without `-save`) | ✅ | ✅ | ❌ | msger creates the WebView invisible (`with_visible(false)`) but still loads HTML and runs scripts — an embedded `<script>` can query the engine and `window.ipc.postMessage` a result back. Combined with `-result <fieldname>` for clean stdout, this lets msger act as a headless CSS/JS resolver (`contrast-color()`, `getComputedStyle()`, `CSS.supports()`). msgview matches with `BrowserWindow({show:false})` + `backgroundThrottling:false`. |
-| Render to bitmap (`-render [file]`, `render` option) | ✅ | ✅ | ❌ | Headless page→image capture: the window is never shown; the page loads, settles (`renderDelay`, default 100ms after `load` + two rAFs), is screenshotted, and the host exits. `-render <file>` writes the image (format from extension: `.png`/`.jpg`/`.bmp`) and the JSON result carries `render: {path, width, height, format}`; bare `-render` (or API `render: true`) returns it as `render: {data (base64), width, height, format}`. Library API: `showMessageBox({render: "shot.png" \| true, renderDelay?, renderFormat?})`; a failed capture rejects (msger) or sets `renderError` in the result. Both hosts fall back to capturing whatever rendered if the page hasn't loaded within the timeout (default 30s in render mode). msger: WebView2 DevTools `Page.captureScreenshot` — **Windows only** for now; msgview: `webContents.capturePage()` — all Electron platforms. Width/height are physical pixels (include DPI scale). |
+| Render to bitmap (`-render [file]`, `render` option) | ✅ | ✅ | ❌ | Headless page→image capture: the window is never shown; the page loads, settles (`renderDelay`, default 100ms after `load` + two rAFs), is screenshotted, and the host exits. `-render <file>` writes the image (format from extension: `.png`/`.jpg`/`.bmp`) and the JSON result carries `render: {path, width, height, format}`; bare `-render` (or API `render: true`) returns it as `render: {data (base64), width, height, format}`. Library API: `showMessageBox({render: "shot.png" \| true, renderDelay?, renderFormat?})`; a failed capture rejects (msger) or sets `renderError` in the result. Both hosts fall back to capturing whatever rendered if the page hasn't loaded within the timeout (default 30s in render mode). msger: WebView2 DevTools `Page.captureScreenshot` on Windows, `webkit_web_view_get_snapshot()` → cairo PNG on Linux/Pi (2026-08-01); msgview: `webContents.capturePage()`. Both msger paths produce the same base64 PNG, so format transcoding and file writing are shared. **Linux caveat:** WebKitGTK cannot snapshot a window that was never mapped, so on Linux the render window IS mapped — made invisible by going fully transparent and skipping the taskbar, since Wayland has no way to park a window off-screen. Width/height are physical pixels (include DPI scale) and cover the WebView viewport, not the window frame. |
 
 > **msger** now injects `window.msgapi` via `msger-api.js` with window control, UDP, and HTTP. File system and shell are not yet implemented in msger or msgview.
 >

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bobfrankston/msgapidefs",
-  "version": "0.1.37",
+  "version": "0.1.38",
   "description": "TypeScript definitions for msgapi JavaScript API (msgview/msger)",
   "type": "module",
   "main": "./msgapidefs.js",