fix(gui): draw a client-side titlebar on Linux for window controls

[stefan-siebert]

Problem

On Linux every window opens with no titlebar and no window controls (minimize / maximize / close). All windows use appears_transparent: false, but on Linux the compositor declines server-side decorations and gpui falls back to client-side decorations it does not paint — so there's nothing to drag and no controls. macOS and Windows are unaffected (their native titlebar works), so this is a Linux-only gap.

Startup log on Wayland:

gpui_linux::linux::wayland::window: Server-side decorations requested, but the
Wayland server does not support them. Falling back to client-side decorations.

Fix

Draw gpui-component's TitleBar (window controls + drag region) on Linux, scoped behind cfg!(target_os = "linux") so macOS and Windows keep their native titlebar unchanged:

• Window options go through a shared windows::titlebar_options() helper: on Linux it returns TitleBar::title_bar_options() (transparent native chrome); on macOS/Windows it returns the original native options. Used by the main window (main.rs) and the aux-window opener (windows/mod.rs).
• The main view (app.rs) and each auxiliary view — Settings, Add Device, Update Consent — render a TitleBar at the top via a shared windows::aux_title_bar() helper, each gated on Linux.
• The Settings window uses an absolute-overlay titlebar (with matching top padding) rather than a flex-column row, because its h_resizable sidebar uses percentage sizing that a flex column would break.

Scope & testing

• macOS / Windows: byte-for-byte unchanged — the native titlebar options and render paths are preserved; the TitleBar is only added under cfg!(target_os = "linux"). (The one non-gated change, an inner flex_1 wrapper in two aux views, is visually neutral.)
• Linux: verified — builds clean, clippy clean, the app launches and the window stays up with the client-side titlebar on the CSD path.

Note: this is independent of the appearance-observer crash fix (#337) — it touches different files and neither depends on the other. But master currently panics on launch on Linux (that's #337), so to run this branch in isolation you'll want #337's one-line fix present; reviewing the diff needs nothing.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR adds Linux client-side titlebars while keeping native titlebars elsewhere.

• Shared titlebar options for main and auxiliary windows.
• Linux-only rendered titlebars for the main, Settings, Add Device, and Update Consent windows.
• Localized Settings window title text in both native and Linux titlebar paths.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
crates/openlogi-gui/src/windows/settings.rs	Uses a localized Settings title and adds a Linux-only overlay titlebar with top padding.
crates/openlogi-gui/src/windows/mod.rs	Adds shared helpers for platform-specific titlebar options and auxiliary client-side titlebars.
crates/openlogi-gui/src/app.rs	Adds a Linux-only client-side titlebar to the main app view.
crates/openlogi-gui/src/windows/add_device.rs	Adds a Linux-only auxiliary titlebar above the Add Device content.
crates/openlogi-gui/src/windows/update_consent.rs	Adds a Linux-only auxiliary titlebar above the update consent content.
crates/openlogi-gui/src/main.rs	Routes main window titlebar setup through the shared platform helper.

_{Reviews (2): Last reviewed commit: "fix(gui): draw a client-side titlebar on..." | Re-trigger Greptile}

[stefan-siebert]

Thanks! Good catch on "Settings Title Skips Localization" — that was a real inconsistency I introduced (add_device and update_consent localize their titlebar labels with tr!(...), the Settings one didn't).

Fixed in the latest push. I localized it in both places for the Settings window, to match the add_device pattern and avoid a new mismatch:

• the client-side titlebar label: aux_title_bar(tr!("Settings"), cx);
• the OS window title passed to open_or_focus: tr!("Settings") (it was a plain "Settings" literal too, so localizing only the titlebar would have left the taskbar title English while the in-window title translated).

Builds + clippy clean.

[recchia]

Heads up @stefan-siebert — #191 also edits main_window_options() in crates/openlogi-gui/src/main.rs, specifically the app_id field (switches the hardcoded "openlogi" literal to the shared brand::APP_ID constant so it matches the .desktop file's StartupWMClass for Wayland frontmost-window detection) and the same gpui import line you're trimming. Both PRs touch the same few lines in that function, so whichever lands second will likely need a small conflict resolution — wanted to flag it before either of us rebases.

[stefan-siebert]

Quick heads-up: #191 also touches main_window_options() and open_or_focus(), so whichever of us merges second is going to hit a little conflict in those two WindowOptions blocks (and the windows/mod.rs import list). Nothing scary — both branches merge clean against master on their own, it's just the overlap between them.

When it happens, it's a take-both: keep this PR's new imports (TitleBar, div, etc.) plus #191's APP_ID import, use #191's app_id: Some(APP_ID.into()), and keep my titlebar_options(...).

One thing to watch: this branch still has app_id: Some("openlogi".to_string()) sitting there as context, so it's easy to accidentally keep the hardcoded string and lose #191's APP_ID — that would quietly undo the Wayland WM_CLASS fix. And I can't just switch to APP_ID here pre-emptively, since #191 is the PR that adds that constant.