Set Default Connection for Companion Dashboard (web UI, next to Toggle Fullscreen)

[dubpixel]

Summary

Add a "Set Default Connection" control to the web UI's Mode tab, next to the existing Toggle Fullscreen button — lets someone pre-configure which Companion instance Dashboard points at from dpx-buttonode-ui directly, instead of needing to open Dashboard's own on-screen settings after every enable.

Research findings (important — changes the naive approach)

Read tomhillmeyer/companion-dashboard's actual source (src/SettingsMenu.tsx, src/main.js) before scoping, since a naive "write a config file" implementation would not work:

• The connection URL is stored in localStorage, keyed per-window-ID: window_${windowId}_companion_connection_url (SettingsMenu.tsx line 30). windowId is assigned dynamically at runtime (window creation counter in main.js), not a fixed/predictable value we can target ahead of time.
• Electron's localStorage backs onto a Chromium "Local Storage" leveldb directory under app.getPath('userData') — not a flat JSON file we can safely edit from a shell script. Format is undocumented/version-dependent.
• main.js already reads process.argv for a --kiosk-mode flag (this project's own launch command uses it) — this is the one existing precedent for "configure Dashboard's behavior externally at launch," but there's currently no equivalent flag for a default connection URL.
• A dashboard-configuration-v1.0.0.json demo file exists in their repo (config import/restore feature, onConfigRestore callback) — worth checking whether this can be loaded via a CLI arg or file association at startup, as a possible existing hook, before assuming a new upstream feature is required. Not fully verified this pass.

Proposed approach

Do not attempt to write directly into Dashboard's localStorage/leveldb store — fragile, undocumented, and the per-window key can't be predicted ahead of a fresh launch.

Two real options, in order of preference:

1. Upstream contribution to companion-dashboard: add a --default-connection-url=<url> CLI flag, read in main.js alongside the existing --kiosk-mode check, applied to the renderer only when no localStorage value is already set for that window (so it's a one-time default, not an override that fights the user's own later changes). This is the correct fix — matches their existing pattern, doesn't fight their architecture. Would need a PR against their repo, or at minimum an upstream issue first to gauge whether they'd accept it.
2. Verify the config-import file mechanism as a possible existing hook (check whether onConfigRestore can be triggered by a file path at launch, e.g. --config=<path> or a file association) — if it already exists, our install-dashboard.sh/dpx-dashboard.service could pass a pre-generated config file pointing at whatever Companion instance the device is already configured to use (e.g. reusing /etc/dpx-satellite.conf's host/port as the natural default), no upstream change needed. Not yet confirmed this pass — next step before committing to option 1.

What our side would need either way

• src/dpx-buttonode-ui/dpx-buttonode-ui.py: new field/button next to Toggle Fullscreen on the Mode tab's Dashboard section, POST route to set/persist the chosen default connection URL (probably reusing the existing Satellite host/port config as a sensible pre-fill, since that's already the "which Companion instance does this unit talk to" answer for the rest of the appliance)
• Depends entirely on which of the two approaches above pans out — option 1 also needs upstream buy-in/a merged PR before this is usable, which is out of our control and could stall the feature indefinitely; option 2 is self-contained if the hook actually exists.

Out of scope for this pass

• Any UI for managing multiple named connections (Dashboard already has its own multi-connection UI) — this is specifically about the default/pre-filled one.
• Implementation — this issue is scoping only, per explicit request.