Skip to content

Add optional frameless Linux desktop windows - #1785

Open
salemsayed wants to merge 2 commits into
get-bb:mainfrom
salemsayed:feat/linux-frameless-window
Open

Add optional frameless Linux desktop windows#1785
salemsayed wants to merge 2 commits into
get-bb:mainfrom
salemsayed:feat/linux-frameless-window

Conversation

@salemsayed

@salemsayed salemsayed commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Summary

  • add a Linux-only --no-window-frame startup option
  • keep the native Electron frame as the default
  • document the option for window managers that provide their own controls
  • cover argument resolution and BrowserWindow construction

Why

Tiling Wayland compositors such as Hyprland already provide window movement,
resizing, borders, and close controls. Electron's native Linux menu/title bar
duplicates that chrome and consumes vertical space. This opt-in mode lets those
users rely on their window manager without changing the default experience for
other Linux desktops.

The option is startup-only because Electron chooses frame when constructing a
BrowserWindow. macOS and Windows ignore the Linux-only flag.

Screenshots

Before — native Linux frame:

bb with the native Linux frame

After — --no-window-frame:

bb without the native Linux frame

Validation

  • pnpm --filter @bb/desktop test — 34 files, 217 tests passed
  • pnpm --filter @bb/desktop typecheck
  • focused Prettier and git diff --check
  • built bb-0.38.0-x86_64.AppImage
  • launched native-frame and frameless AppImages side by side on Hyprland with isolated data and ports
  • verified the frameless native Wayland window, server health, and host-daemon listener

@salemsayed
salemsayed marked this pull request as ready for review August 18, 2026 15:29
ymichael added a commit that referenced this pull request Aug 24, 2026
## What was wrong

The Pi bridge tests exercise real Node child processes, but the two
install-gate cases that cold-start the catalog child inherited Vitest’s
5 s default and the conformance wrapper passed only a 10 s per-wait
protocol budget. Under the 4-vCPU packages shard contention, the same
fork-helper path took 11.47 s in its correctly budgeted lifecycle test,
so these smaller limits expired while valid bridge work was still
running. Vitest does not cancel a timed-out async body; because each
install-gate scenario then reused JSON-RPC request id `1` with a fresh
stdout capture, a late response from the timed-out scenario could
satisfy the next test and produce the unsupported/not-installed
assertion cascade. The failures are visible in the [main
run](https://github.com/get-bb/bb/actions/runs/32699848174) and
unrelated [PR
#1781](https://github.com/get-bb/bb/actions/runs/32718468577) and [PR
#1785](https://github.com/get-bb/bb/actions/runs/32718467431) runs.

## What changed

The two install-gate cases that actually cold-start RPC children now use
the same 30 s class of test budget as the neighboring Pi process tests,
and conformance waits up to 30 s for each protocol response while
retaining the existing 60 s wrapper. Install-gate request ids are
monotonic across the file, so any late result remains diagnostic noise
instead of being mistaken for another scenario’s response. Assertions
and production behavior are unchanged. This is test-only and does not
change the host-daemon wire protocol.

## How you verified

Before the change, the cited CI runs crossed the old limits, and a
controlled local stress run with 64 competing CPU burners stretched the
unchanged conformance test to 18.4 s and the two install-gate process
cases to 4.64 s and 4.35 s. After the change, three identical stress
rounds passed all 6 focused tests; conformance took 12.01 s, 11.96 s,
and 11.87 s without losing `session/fork-identity`.

- `pnpm exec vitest run src/bridge/bridge.install-gate.test.ts
src/bridge/bridge.conformance.test.ts --config vitest.config.ts
--reporter=dot --maxWorkers=1` — 6 passed
- `pnpm exec turbo run test --filter=bb-plugin-provider-pi --force` — 17
files, 104 tests passed
- `pnpm exec turbo run typecheck --filter=bb-plugin-provider-pi --force`
— 4 Turbo tasks passed
- `pnpm exec turbo run build --filter=@bb/server --force` — 4 Turbo
tasks passed
- `pnpm exec oxfmt
plugins/provider-pi/src/bridge/bridge.install-gate.test.ts
plugins/provider-pi/src/bridge/bridge.conformance.test.ts --check` —
passed

> AGENT GENERATED: by GPT-5.6-Sol
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