diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/TODO.md | 8 |
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. |