Skip to content

Add ghost serve --window for a dedicated app window#31

Draft
murrayju wants to merge 1 commit into
mainfrom
murrayju/serve-window-mode
Draft

Add ghost serve --window for a dedicated app window#31
murrayju wants to merge 1 commit into
mainfrom
murrayju/serve-window-mode

Conversation

@murrayju

Copy link
Copy Markdown
Member

Summary

Adds ghost serve --window (alias -w) to launch the web UI in a dedicated system window without an address bar / tab strip, instead of a normal browser tab.

It opens the URL via a Chromium-based browser's --app=<url> flag (Chrome, Chromium, Edge, or Brave), and gracefully falls back to a normal browser tab (with a warning) when no such browser is found. The flag is mutually exclusive with --no-open.

Why this approach (and the trade-offs)

The original request was for a "native OS" way to open a chromeless window. After digging in, the honest reality is that there is no clean native, cross-platform CLI way to do this — "app window without an address bar" is fundamentally a browser/PWA feature, not an OS primitive:

  • Windows — Microsoft Edge is preinstalled on Win 10/11 and is Chromium-based, so --app=<url> works out of the box (effectively native, no extra install).
  • macOS — Safari is native but has no CLI app-mode flag. The only native chromeless option is a WKWebView hosted in our own window.
  • Linux — nothing native or guaranteed.

The genuinely-native route is an embedded OS webview (WKWebView / WebView2 / WebKitGTK, e.g. webview/webview_go), but that requires CGo + a C toolchain for every target, which directly conflicts with our CGO_ENABLED=0 cross-compile pipeline (GoReleaser builds linux/windows/darwin × 386/amd64/arm64 from a single runner). Adopting it would mean per-platform native build runners and a much heavier release setup — a large architectural change for a convenience flag.

So this PR uses the Chromium --app= approach, which:

  • Is not Chrome-specific — it accepts Chrome, Chromium, Edge, or Brave. On Windows that's the built-in Edge, so most users need nothing extra.
  • Is the de-facto standard for this (Vite, Streamlit, VS Code tunnels, etc. all do the same).
  • Degrades gracefully to a normal browser tab when no Chromium browser exists.
  • Has zero impact on the CGO_ENABLED=0 build pipeline.

This is up for discussion — hence the draft. If we'd rather go fully native via an embedded webview (accepting the CGo cost and reworked release pipeline) or drop the chromeless behavior entirely, I'm happy to adjust.

Changes

  • internal/common/browser.go — New OpenAppWindow(url) (a var, like OpenBrowser, for test stubbing). Searches for a Chromium-based browser per platform and launches it with --app=<url>:
    • macOS: /Applications + ~/Applications bundles via open -na <app> --args --app=<url>.
    • Linux: google-chrome / chromium / microsoft-edge / brave-browser on PATH, started detached.
    • Windows: standard install paths under ProgramFiles / ProgramFiles(x86) / LocalAppData for Chrome, Chromium, Edge, Brave.
    • Returns the exported ErrNoAppModeBrowser sentinel when none is found.
  • internal/cmd/serve.go — New --window/-w flag (mutually exclusive with --no-open), an example, and logic to open the app window with a graceful fallback to OpenBrowser.
  • internal/cmd/main_test.gowithOpenAppWindow test option; stubs common.OpenAppWindow by default (mirrors the existing OpenBrowser stub).
  • internal/cmd/serve_test.go — Cases for: successful app-window open (browser not called), fallback to browser when no app-mode browser is found, and the --window/--no-open mutual-exclusion error.
  • docs/cli/ghost_serve.md — Regenerated.

Testing

./check passes (fmt, vet, staticcheck, tests).

Adds a --window/-w flag to ghost serve that launches the web UI in a
standalone application window without an address bar, using a Chromium-based
browser's --app=<url> flag (Chrome, Chromium, Edge, or Brave). Falls back to a
normal browser tab when no such browser is available. Mutually exclusive with
--no-open.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant