Files
Dashward/container/esbuild.config.js
hzhang 5ed4170e69 feat: P4 — DBus bridge + page round-trip + system theme tracking
Three new wires from page to shell and back, proving the bridge end to
end. The dashboard placeholder now follows the system color-scheme via
the full chain: page-side dashShell.call('getTheme') → WebKit script
message handler → DBus method on the shell-owned service → gsettings
read → return value back up. ThemeChanged proves the reverse direction:
the shell watches color-scheme and emits a DBus signal that the
container forwards to the page as a CustomEvent.

extension/src/dbus-service.ts
  Owns top.hangmanlab.Dashward.Shell on the session bus; exports
  GetTheme (reads org.gnome.desktop.interface::color-scheme, maps
  prefer-dark→dark / else→light); emits ThemeChanged on the gsettings
  changed signal. Bus acquisition is async, so the constructor takes an
  onReady callback that fires from the bus_acquired handler.

extension/src/extension.ts
  Sequencing: warden → guard → dbus, and only after dbus_acquired
  callback fires do we spawn ContainerSupervisor. Disable order is
  reversed (container first so its DBus proxy stops calling the service
  before we unown the bus name).

container/src/dbus-client.ts
  Thin GJS proxy wrapper around the Shell interface; exposes a typed
  getTheme() / onThemeChange(cb) API.

container/src/bridge.ts
  Registers a `shellCall` UCM script-message handler; parses
  {id, method, args} JSON from the page, dispatches to invoke(), and
  feeds the result back via evaluate_javascript. Shell signals are
  forwarded to the page via window.__dashShell__._onSignal.

container/runtime/runtime.ts
  Installs window.__dashShell__ at script start, calls getTheme() on
  load and applies the result to <html data-theme>, listens for the
  ThemeChanged CustomEvent.

container/runtime/dashboard.html + esbuild.config.js
  Switched the runtime bundle from `format: 'esm'` to IIFE so it loads
  as a classic <script> -- WebKitGTK silently refuses `<script
  type="module">` over file:// for ES module resolution. Added an
  inline error catcher that surfaces JS errors in the visible boot
  diagnostic div instead of failing silently.

container/src/main.ts
  Construct ShellClient + Bridge before load_uri so the very first
  page-side dashShell.call() has a handler waiting. Added load-changed
  / load-failed signal logging for future diagnosis.

Verified on ubuntu2504-test VM: enable produces clean log chain through
"container window arrived", page renders with "P4 — shell bridge
online" placeholder and the correct system theme on first paint, manual
`gsettings set ... color-scheme prefer-dark` flips the placeholder
background live.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-23 00:54:19 +01:00

38 lines
960 B
JavaScript

import esbuild from 'esbuild';
const watch = process.argv.includes('--watch');
const gjsOpts = {
entryPoints: ['src/main.ts'],
bundle: true,
outfile: 'dist/main.js',
format: 'esm',
target: 'firefox128',
platform: 'neutral',
external: ['gi://*', 'system', 'cairo', 'gettext'],
sourcemap: 'inline',
logLevel: 'info',
};
const runtimeOpts = {
entryPoints: ['runtime/runtime.ts'],
bundle: true,
outfile: 'dist/runtime.js',
// IIFE so it loads as a classic <script>, avoiding WebKitGTK's
// file:// module loader quirks (the original `type="module"` script
// simply didn't execute).
format: 'iife',
target: 'es2022',
platform: 'browser',
sourcemap: 'inline',
logLevel: 'info',
};
if (watch) {
const c1 = await esbuild.context(gjsOpts);
const c2 = await esbuild.context(runtimeOpts);
await Promise.all([c1.watch(), c2.watch()]);
} else {
await Promise.all([esbuild.build(gjsOpts), esbuild.build(runtimeOpts)]);
}