fix(gui): draw the client-side titlebar only where the compositor declines one - #945
Open
4ni1ak wants to merge 1 commit into
Open
fix(gui): draw the client-side titlebar only where the compositor declines one#9454ni1ak wants to merge 1 commit into
4ni1ak wants to merge 1 commit into
Conversation
Greptile SummaryThe PR replaces the unconditional Linux client-side titlebar with a per-window decision based on the decoration mode negotiated with the compositor.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| crates/openlogi-desktop/src/windows.rs | Adds the shared decoration-mode predicate and updates documentation for Linux titlebar behavior. |
| crates/openlogi-desktop/src/app.rs | Makes the main window’s custom titlebar conditional on negotiated client-side decorations. |
| crates/openlogi-desktop/src/windows/add_device.rs | Applies the shared decoration decision to the Add Device window. |
| crates/openlogi-desktop/src/windows/settings.rs | Applies the shared decoration decision while preserving the Settings window’s overlay and padding layout. |
| crates/openlogi-desktop/src/windows/update_consent.rs | Applies the shared decoration decision to the update-consent window. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Render window] --> B{Negotiated decorations}
B -->|Client| C[Draw OpenLogi titlebar]
B -->|Server| D[Use compositor titlebar]
C --> E[Render window content]
D --> E
Reviews (2): Last reviewed commit: "fix(gui): draw the client-side titlebar ..." | Re-trigger Greptile
…lines one Every Linux window drew its own titlebar unconditionally. That is right on GNOME — Mutter does not implement `xdg-decoration`, gpui falls back to client-side, and nothing paints the chrome unless the app does — but KWin does implement it and hands back a real server-side titlebar. On KDE the two stacked: the compositor's bar, and ours with its own minimize/maximize/close underneath it. Ask the window what it actually got instead of assuming. `needs_client_titlebar` reads `Window::window_decorations()` and is true only for `Decorations::Client`, which is also what macOS and Windows never report — so the four render sites lose their `cfg!(target_os = "linux")` and gain one honest check that reads the same on every platform. Fixes AprilNEA#890
4ni1ak
force-pushed
the
fix/kde-double-decoration
branch
from
August 25, 2026 15:20
e57f71c to
ec9f567
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
On KDE the compositor's titlebar and OpenLogi's own were both visible, stacked.
Fixes #890
Root cause
Every Linux window drew a client-side titlebar unconditionally:
The comment beside it explained why — "the compositor declines server-side
decorations and gpui's client-side fallback is otherwise unpainted" — and that
is true of GNOME: Mutter does not implement
xdg-decoration, so without thisthe window has no chrome at all. It is not true of KWin, which does implement
it and hands back a real server-side titlebar.
cfg!(target_os = "linux")reads"Linux" as if it were one compositor.
Change
Ask the window what it actually negotiated:
The four render sites — main window, Settings, Add Device, the update-consent
prompt — drop their
cfg!for that call. macOS and Windows always reportServer, so the platform check disappears rather than moving: one conditionthat reads the same everywhere.
titlebar_options()still returns transparent options on Linux — that is whatpermits a client-side bar. Whether one is drawn is now decided per window from
what the compositor said, and its doc comment now says so.
The issue also asks for a preference to choose the decoration type. That is not
here: with this, each compositor gets exactly the one it asked for, and a
setting would mostly exist to re-create the wrong half. Happy to add one if you
would still like it.
Testing
Linux, x86_64, Rust 1.98.0:
All green.
Verified visually on the reported platform — KDE Plasma, Wayland,
kwin_wayland, the same class as the report's KDE Neon:master, both the main window and the update-consent prompt show twotitlebars: KWin's, and below it a second bar reading "OpenLogi" with its own
minimize / maximize / close.
the pin button intact.
Same session, same compositor, GUI rebuilt between the two runs, screenshots
compared side by side.
Not verified: GNOME. That is the case the unconditional draw existed for, so
it is the one to re-check — a window with no titlebar there would mean
window_decorations()is not reportingClientas expected. Also not run onthis host:
tests (macos),cargo-deny, macOS clippy; macOS and Windows areunchanged by construction (both always report
Server, exactly ascfg!(target_os = "linux")was false for them).