srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/crates/wayland
diff options
context:
space:
mode:
authorsrdusr <[email protected]>2026-06-01 23:18:00 +0200
committersrdusr <[email protected]>2026-06-01 23:18:00 +0200
commit3ef784e09f6b81b767837e048d691c4e63528e55 (patch)
tree0f96600eff4028d93f12764a79c02dea69434bc8 /crates/wayland
parent27daed83230eaefd0f41461cad20bbed7d1ad575 (diff)
downloadsrdwm-3ef784e09f6b81b767837e048d691c4e63528e55.tar.gz
srdwm-3ef784e09f6b81b767837e048d691c4e63528e55.zip
Let negotiating clients be forced to server-side decoration, and document the GTK half
Asked to research how KDE and GNOME make decorations consistent, after being told too quickly that srdwm could only control its own titlebar. Measured against a nested srdwm, one client at a time: Qt/KDE creates a decoration object and asks for server-side; winit creates one and asks for CLIENT-side; GTK never creates one at all. The xdg-decoration spec says the compositor "can decide not to use the client's mode and enforce a different mode instead" and that the client "must obey" - so the first two are srdwm's to decide, and it had simply been deferring. The same spec closes the door on the third: a client that does not negotiate continues to self-decorate, and GTK is not having the conversation. New theme.decorations.force_server_side, default off, overrides the client's requested mode. Verified: with it off Alacritty draws its own content to the window's top edge, with it on the same window gets srdwm's titlebar -- (0,0,0) versus (46,52,64) sampled at three rows. Off by default because it cannot move a GTK button and can stack srdwm's titlebar on a client that draws its own regardless, which is the Firefox case already recorded here. The GTK half needs no compositor code, only the desktop setting GTK actually reads - xdg-desktop-portal's org.gnome.desktop.wm.preferences button-layout for GTK4, gtk-decoration-layout for GTK3. This machine was serving "close,minimize,maximize:" (left) while srdwm's own button_side was right, which is the entire mismatch. Documented in DEFAULTS.md with the mapping from button_side to layout string, and noted that this is exactly what kde-gtk-config does for KWin. 525 tests pass, clippy clean.
Diffstat (limited to 'crates/wayland')
-rw-r--r--crates/wayland/src/protocols/xdg_decoration.rs5
1 files changed, 5 insertions, 0 deletions
diff --git a/crates/wayland/src/protocols/xdg_decoration.rs b/crates/wayland/src/protocols/xdg_decoration.rs
index 25973c0..c3c7f0b 100644
--- a/crates/wayland/src/protocols/xdg_decoration.rs
+++ b/crates/wayland/src/protocols/xdg_decoration.rs
@@ -37,7 +37,12 @@ impl XdgDecorationHandler for CompState {
/// the way for exactly those clients, while everything that accepts
/// (or has no preference and gets offered) server-side still gets our
/// titlebar as before.
+ /// `theme.decorations.force_server_side` overrides the client's request
+ /// - see `ThemeConfig::force_server_side` for why that is allowed and
+ /// why it is off by default.
fn request_mode(&mut self, toplevel: ToplevelSurface, mode: DecorationMode) {
+ let forced = self.wm.borrow().theme.force_server_side;
+ let mode = if forced { DecorationMode::ServerSide } else { mode };
toplevel.with_pending_state(|state| {
state.decoration_mode = Some(mode);
});