srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/TODO.md12
1 files changed, 12 insertions, 0 deletions
diff --git a/docs/TODO.md b/docs/TODO.md
index 67ff09a..fbe5ec9 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -1,5 +1,17 @@
# TODO / planned features - master checklist
+## Three real bugs found from one screenshot: window memory never saved on close, split screens duplicated desktop icons, split parts all claimed primary (2026-08-27)
+
+Asked directly why windows always spawn top-left and don't remember placement/size, and to screenshot the just-split display since it "doesn't look like 2 more monitors, just showing double desktop icons." Took a real `grim` screenshot rather than guessing from code, and it showed both reported symptoms at once plus revealed why the first one happens at all.
+
+**Window memory only ever saved on a manual drag/resize release.** `WindowManager::remembered_geometry` (per-`app_id` last floating position+size, read at window-map time) was real and correctly wired on the *read* side, but the only two places that ever wrote to it were `end_drag`/`end_resize` in `dragresize.rs` - a real user action, mouse button released after actually dragging or resizing. An app the user opens, looks at, and closes without ever touching its edges or titlebar had nothing recorded at all, so reopening it always fell back to a fresh cascade placement - indistinguishable from the feature not existing, for what is probably the *majority* of ordinary window lifecycles. Fixed by also snapshotting geometry into `remembered_geometry` from `WindowManager::remove_window` itself (gated the same `app_id`-non-empty way the drag/resize sites already are), and persisting it to disk at both of `remove_window`'s two wayland-side call sites (`state/lifecycle.rs`'s native unmap path, `xwayland.rs`'s X11 equivalent) the same way `input/pointer.rs`'s drag/resize-release site already does.
+
+**A split screen mirrored the full desktop-icon set onto every split part.** `desktop_icon_origins`'s "mirror icons onto every monitor" mode (`general.desktop_icons_all_monitors`, the default) iterated every `Monitor` entry `srd monitors` reports - which, after a `srd.monitor.split`, includes one entry *per split part*, not one per real physical screen (see `Monitor::split`'s own doc comment: "not a second wl_output, not a second physical connector"). Two icon columns side by side on what is still one continuous physical desktop read as a visual bug, not "2 more monitors" - which is exactly the screenshot. Fixed in a new, separately-testable `icon_origins_for` (pulled out of `desktop_icon_origins` the same way `udev/outputs.rs::next_logical_x` was pulled out of `relayout_outputs`): a split part's name is always `"{connector}-{part}"`, so recovering the connector and keeping only the lowest-id part per connector collapses every split group back to the one real screen it is, while a genuinely separate monitor (real or fake) still gets its own origin.
+
+**Every split part reported `primary: true`, not just one.** Found while fixing the above: `platform.rs`'s per-part loop computed `m.primary` from the *connector's* name, which doesn't change across `0..parts`, so a primary connector's split produced two-or-more `Monitor` entries all claiming primary - silently broke the "exactly one primary monitor" assumption several callers reasonably make (including the icon-origin fix's own single-monitor branch, which just took whichever `.find(|m| m.primary)` matched first). Fixed by gating on `part == 0` too.
+
+Full workspace build/test/clippy clean (224 core / 146 wayland tests, both up from before). Not yet live-verified against a real restart - needs one, same as everything else this session.
+
The single consolidated list of pending work. Before this file, "what's
left" was scattered across four places that each grew their own list
independently (`MISSING.md`, `PANEL_SUPPORT_TODO.md`,