jgamboaandClaude
0eb5608873
Electrobun 2.x replaces the vendored CLI with Hutch: the npm package is now a
bootstrap whose exports are a throwing stub, and the SDK is projected into
.hutch/devkit. The app stays on the Bun main process — `mainProcess: "bun"` is
load-bearing, since the 2.x default (Cottontail) ignores build.bun and with it
the ssh2 externals — and the bundle now ships the pinned Bun 1.4.0.
- electrobun 2.0.2 as an exact devDependency. `electrobun prepare` takes the
old CLI re-sign step's slot in postinstall and every dev/build/start/release
script: tsc (root tsconfig extends the devkit's) and the Angular build
(electrobun/view mapped into the devkit) resolve the SDK there.
- Imports move to electrobun/main. The CLI re-sign script and the v1 "three"
type shim are gone (Hutch's binaries are validly signed).
- UI: Electroview's bunSocket is hostSocket; noImplicitReturns is off because
the devkit's raw-TS browser SDK compiles inside the UI program.
- Updater.applyUpdate() now consults before-quit, so the transfers/unsaved
guard's "Quit Anyway" re-runs the apply instead of quitting without it.
- 2.x applies trafficLightOffset from macOS's default button position (1.18.1
clamped it inside the titlebar); {12, 4} centres the lights in the header.
- Releases: mac-x64 dropped (2.x publishes no macOS x64 core, so no Rosetta
path). artifacts/ is emptied before each build and published verbatim.
Installers lost the stable- prefix (the update feed kept it), so release.ts,
deploy.sh and the site links follow. Linux ships Electrobun's Setup
installer instead of the portable tarball and its miniSCP.sh wrapper.
- Docs cover all of the above, plus re-checks against 2.0.2: still no native
modal windows; window close is now cancellable through will-close.
Verified: tsc, build:ui, a stable mac-arm64 release (dmg + the v1-compatible
stable-macos-arm64 feed) and dev launches (RPC, Settings window, traffic
lights). Windows/Linux builds and the v1 -> 2.x Windows update bridge still
need their first run on native machines.
Co-Authored-By: Claude <noreply@anthropic.com>
35 lines
1.5 KiB
TypeScript
35 lines
1.5 KiB
TypeScript
// PORTABILITY: WebKitGTK's DMABUF renderer cannot allocate GBM buffers on the
|
|
// NVIDIA proprietary driver — the app window paints BLACK and stderr fills with
|
|
// "Failed to create GBM buffer of size WxH: Invalid argument" (usually with an
|
|
// "X11 Error: GLXBadWindow" alongside). Disabling that renderer path is the
|
|
// standard upstream workaround.
|
|
//
|
|
// It has to be in the environment BEFORE the app process starts: WebKit reads
|
|
// it when it forks its web process, and Bun's `process.env` writes do NOT
|
|
// propagate to children (verified — a child sees the variable unset), so the
|
|
// app cannot set this for itself from inside src/bun/. Only the dev launch
|
|
// paths (`bun run dev` / `bun run start`) inject it; an installed build (the
|
|
// official Linux Setup installer) needs the user to set
|
|
// WEBKIT_DISABLE_DMABUF_RENDERER=1 themselves on NVIDIA.
|
|
//
|
|
// Scoped to NVIDIA so Intel/AMD keep hardware compositing, and an explicit
|
|
// value from the user's environment always wins.
|
|
import { existsSync } from "node:fs";
|
|
|
|
export function needsDmabufWorkaround(): boolean {
|
|
return (
|
|
process.platform === "linux" &&
|
|
process.env.WEBKIT_DISABLE_DMABUF_RENDERER === undefined &&
|
|
existsSync("/proc/driver/nvidia")
|
|
);
|
|
}
|
|
|
|
/** `process.env` plus the workaround, ready to hand to Bun.spawn. */
|
|
export function launchEnv(extra: Record<string, string> = {}): Record<string, string | undefined> {
|
|
return {
|
|
...process.env,
|
|
...(needsDmabufWorkaround() ? { WEBKIT_DISABLE_DMABUF_RENDERER: "1" } : {}),
|
|
...extra,
|
|
};
|
|
}
|