diff options
| author | srdusr <[email protected]> | 2026-06-02 20:08:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-06-02 20:08:00 +0200 |
| commit | 30d45a7b9e0ddcd7ed2836c16e77b423cf3cff28 (patch) | |
| tree | e7a85ad53642184b73afe7b8d47e9ef206d1b342 /LICENSE | |
| parent | 3ef784e09f6b81b767837e048d691c4e63528e55 (diff) | |
| download | srdwm-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 'LICENSE')
0 files changed, 0 insertions, 0 deletions