Let a new window pick its own size instead of forcing a guessed placeholder

Root-caused "windows spawn small and square, not remembering placement or
size": new_managed_window hardcoded a fresh toplevel's geometry to 800x632
before the client had said anything about its own preferred size, and
sync_geometry forced that guess onto the client's very first
xdg_toplevel::configure unconditionally. Per xdg-shell, size: None on that
first configure is how every mainstream compositor lets a client pick its
own natural size instead; this one never did, so every app converged on
the same placeholder rectangle regardless of what it would have chosen.

Window::size_is_provisional marks a size that really was just the guess
(not a remembered geometry, a rule's explicit geometry action, or a
maximize/phone-mode fill, none of which are guesses). sync_geometry sends
size: None for such a window's first configure; a new adopt_provisional_size,
called from the commit handler, adopts the client's own real first size
into Window::geometry the moment it commits one, clamping only position so
a bigger-than-guessed window can't hang off its monitor's edge.

Live-verified in a nested compositor: a zenity dialog now renders at its
own compact natural size instead of being stretched to the old guess.

1 files changed, 8 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index eba054c..c212993 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -1,5 +1,13 @@
 # TODO / planned features - master checklist
 
+## Root cause found and fixed: every new window forced to the same guessed size, never its own (2026-08-28)
+
+Asked directly why windows "spawn small and as a square" and not centred, on top of the already-fixed "don't remember placement" bug. Read the actual code path rather than guessing, and found the real cause: `new_managed_window` hardcodes a brand-new toplevel's `Window::geometry` to `800x632` (800x600 plus the titlebar band) *before* the client has said anything about its own size, `WindowManager::add_window` feeds that same guessed number into `SmartPlacement` as if it were real, and - the actual bug - `sync_geometry` then forces that guessed size onto the client's very first `xdg_toplevel::configure` via `state.size = Some(size.into())`, unconditionally, on every single new window. Per the xdg-shell protocol, `size: None` on that first configure is the standard way every mainstream compositor (Mutter, KWin, Hyprland, sway, niri) lets a client pick its own natural size; this compositor never did, so every app - a tiny dialog and a browser alike - was flattened onto the exact same placeholder rectangle regardless of what it would have chosen for itself. That is why windows read as "the same size, small, square" rather than each app looking like itself.
+
+Fixed with a new `Window::size_is_provisional` flag, set by `add_window` only when the size it just used really was nothing but the placeholder guess - not when a remembered geometry, a rule's own explicit `geometry` action, or a phone-mode/maximize fill decided the size instead, since none of those are guesses and must never be second-guessed by whatever the client defaults to. A backend (currently just the Wayland one; XWayland/X11 already share `add_window` and could get the same treatment later) tracks membership in a new `CompState::provisional_size` set: `sync_geometry` sends `size: None` instead of the guess for that one window's first configure, and a new `adopt_provisional_size` - called from `CompositorHandler::commit` right after `on_commit()` recomputes the client's real content geometry - adopts whatever real size the client picked for itself into `Window::geometry` the moment its first non-empty buffer commit arrives, clamping only the *position* so a client that picked something bigger than the old guess can't hang off its monitor's edge. Cascade/grid placement's own *position* choice is left alone throughout - only the size was ever wrong.
+
+Live-verified in a nested compositor (`WAYLAND_DISPLAY=wayland-1`, winit backend, never the live session): a plain `zenity --info` dialog previously would have been stretched to the old guessed box; with this fix it renders at its own real, compact natural size (screenshotted via `grim`), titlebar sized to match. Full workspace build/test/clippy clean (237 core tests, +4 for `size_is_provisional`'s own remembered/rule/maximize-are-never-provisional invariants; 152 wayland, unchanged in count but exercising the new path via the nested test above).
+
 ## Lock screen: real content, not a bare box, plus a working on-screen keyboard (2026-08-28)
 
 Asked directly: the native lock UI "shouldn't show a square, looks ugly/AI like," should have "other features like a normal lock," and needs a virtual keyboard. Read `render_ui_box` cold and the complaint was accurate - a flat, bordered rectangle with three left-aligned text lines (username, password dots, status), no clock, no avatar, no shadow. Every mainstream lock screen (GNOME, macOS, Windows) shows a clock/date and some identity marker; this one showed neither.