srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/crates/wayland/src/state
diff options
context:
space:
mode:
authorsrdusr <[email protected]>2026-06-02 20:08:00 +0200
committersrdusr <[email protected]>2026-06-02 20:08:00 +0200
commit30d45a7b9e0ddcd7ed2836c16e77b423cf3cff28 (patch)
treee7a85ad53642184b73afe7b8d47e9ef206d1b342 /crates/wayland/src/state
parent3ef784e09f6b81b767837e048d691c4e63528e55 (diff)
downloadsrdwm-30d45a7b9e0ddcd7ed2836c16e77b423cf3cff28.tar.gz
srdwm-30d45a7b9e0ddcd7ed2836c16e77b423cf3cff28.zip
Stop window memory poisoning itself, and publish the decoration side to GTK
Two reports, both traced to a cause other than the one being blamed. "Windows still spawn as squares" was not placement. On the live session firefox was 800x632 and so were four other apps, and 800x632 is exactly the placeholder new_managed_window assigns before a client has chosen anything. Firefox's remembered size earlier the same day was 1389x933. The loop: a window closes while still carrying the placeholder, the placeholder is remembered, the next launch therefore has a remembered size and is no longer provisional, a non-provisional window is forced to its size instead of being asked to pick, and on close the placeholder is written back. Every app that ever closed early gets pinned to one identical box, and no amount of placement work can touch it because the size never came from placement. remove_window now refuses to remember a size the client never chose. That alone would have been wrong: adopt_provisional_size cleared its own tracking set but never cleared Window::size_is_provisional, so nothing would ever have been remembered again. Both halves are covered by tests. Five poisoned entries were dropped from the live store and the six real ones kept, with a backup alongside it. "When user sets decorations should override all applications": the earlier answer was true about the protocol and wrong about the outcome. GTK never negotiates decoration, but it does read the desktop's button-layout preference - GTK4 through xdg-desktop-portal, GTK3 through gtk-decoration-layout. srdwm now publishes its own button_side there at startup and after every reload, which is precisely the job kde-gtk-config does for KWin. Verified in both directions from a neutral starting value; testing the second direction is what exposed an ordering bug where the publish ran before apply_general_settings and broadcast the default instead of the configured side. 527 tests pass, clippy clean.
Diffstat (limited to 'crates/wayland/src/state')
-rw-r--r--crates/wayland/src/state/geometry.rs6
1 files changed, 6 insertions, 0 deletions
diff --git a/crates/wayland/src/state/geometry.rs b/crates/wayland/src/state/geometry.rs
index b8629bc..1910334 100644
--- a/crates/wayland/src/state/geometry.rs
+++ b/crates/wayland/src/state/geometry.rs
@@ -556,6 +556,12 @@ impl CompState {
let width = ((content.size.w as f64 * scale).round() as u32).max(srdwm_core::placement::MIN_WINDOW_WIDTH);
let height = ((content.size.h as f64 * scale).round() as u32).max(srdwm_core::placement::MIN_WINDOW_HEIGHT) + band;
let Some(w) = wm.window_mut(id) else { return };
+ // The client has now made a real choice, so this size is no longer
+ // a guess. Clearing the core flag is what lets `remove_window`
+ // remember it: that path deliberately refuses to remember a size
+ // that was never chosen, and without this every window would look
+ // provisional forever and nothing would ever be remembered again.
+ w.size_is_provisional = false;
w.geometry.width = width;
w.geometry.height = height;
if let Some(monitor) = monitor_geometry {