diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/TODO.md | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/docs/TODO.md b/docs/TODO.md index fbe5ec9..785e799 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -1,5 +1,33 @@ # TODO / planned features - master checklist +## Tiling: master/stack ratio is now live, and interactive resize actually does something (2026-08-28) + +Investigated "what happened to tiling" directly. `MasterStackLayout` itself (dwm/i3-style master+stack columns) was already real, tested and correct - gaps live-adjustable, directional swap working, floating/fullscreen correctly excluded. The actual gap: dragging or resizing a tiled window did nothing durable. `start_resize`/`update_resize` had zero tiling awareness - grabbing and dragging a tiled window's border wrote raw geometry exactly like a floating window, which the very next `arrange_workspace` call (triggered by almost anything: a window closing, a focus change) silently discarded, since tiling always fully recomputes every non-floating window's geometry from the master/stack math. On top of that, `master_ratio`/`master_count` were config-file-only - no keybind, no `srd set`, no way to adjust either live the way dwm/i3/Hyprland all let you drag the master/stack boundary or bump master count with a key. + +Fixed both. A resize-drag on the shared master/stack boundary (the master column's own right edge, or any stack window's own left edge - both name the same physical line) now live-adjusts `TilingConfig::master_ratio` and re-arranges every window in the group immediately, the same visual feedback every comparable tiling WM gives; `srd set master_ratio <0.0-1.0>` / `srd set master_count <n>` do the same for a keybind or script (dwm's `mod+h`/`mod+l`/`mod+i`/`mod+d` conventions), re-arranging the current workspace on the spot rather than waiting for gaps' own "next arrange, whenever that happens" laziness. + +**A real bug found and fixed while building this, not just designing it**: `start_resize` already calls `focus_window`, which raises its target to the *end* of `self.order` - the exact list `arrange_workspace` groups master/stack membership from. A first version decided "is this a ratio drag" lazily, inside `update_resize`, *after* that raise had already happened - so grabbing an actual master window's right edge measured its position in the *post*-raise order, where it now looked like the stack's own last slot, and silently misclassified every such drag as a non-drag (falling through to the discarded-raw-geometry path). Caught by this feature's own test suite, not by inspection: a fuller assertion (checking the *other* window's width moved too, not just the grabbed one) failed even though the shallower "did this window's own rect grow" check passed by coincidence via the wrong code path. Fixed by deciding ratio-drag status, and freezing the master/stack membership snapshot it depends on, in `start_resize` itself - *before* the focus-raise - and having the drag apply `MasterStackLayout` directly against that frozen snapshot rather than re-deriving membership from the live (by-then-reordered) `self.order`. + +Live-verified in a nested compositor (`WAYLAND_DISPLAY=wayland-1`, `SRDWM_CONFIG_PATH` pointed at a throwaway `default_layout = "tiling"` config - see this file's own "validate in a nested compositor" convention), not just unit-tested: two real Alacritty windows tiled correctly (master ~60%/stack ~40% at the default ratio), and `srd set master_ratio 0.8` visibly grew the master column from 466px to 623px and shrank the stack from 310px to 153px, confirmed via both `srd clients` and a real `grim` screenshot. Full workspace build/test/clippy clean (231 core tests, +5 for this feature). + +## SettingsResponse readback: everything `srd set` can change can now be read back (2026-08-28) + +Flagged directly by the AGS peer session, who named the shared pattern behind several separate gaps at once: "a control whose value cannot be read back is a control that lies on every restart." `border_width`, `border_color`, `corner_radius`, `decoration_mode`, `gap_inner`, `gap_outer` were all live-settable via `srd set` with no way to read the *current* value back at all - a settings panel could set any of them blind, but never confirm a set took or show its own control's honest starting position. `master_ratio`/`master_count` (this session's own tiling work, just above) got the same treatment from the start rather than repeating the gap. + +Also closed the same way: Multi-cursor Phase 2 (`srd dispatch pin input`) had no readback either - a caller could pin a window blind but never ask "is pid X pinned to anything right now." `CompState::set_virtual_pointer_pin` (the Wayland backend's own confirmation that a pin was genuinely applied, not just requested) now also mirrors the pinned/unpinned state into a new `WindowManager::pinned_windows` map, readable via a new `{"cmd":"pinned_inputs"}` query (`srd pinned inputs`). + +`border_color`'s readback is a `#rrggbb` string via a new `srdwm_core::format_hex_color` - `parse_hex_color`'s exact inverse, so a caller can feed a read-back value straight into another `set` unchanged. + +Full workspace build/test/clippy clean (39 platform tests, up from 34). + +## X11: maximize left a window sitting past the screen edge with a real border (2026-08-28) + +Found and fixed on a report from the `aegis-fc` peer session (a Rust AGS-successor client, testing srdwm's own layer-shell strut handling): a maximized X11 client sat 4-8px past the right and bottom screen edges whenever its border was nonzero. Root cause: `set_border_width` sets the frame window's *native* X11 `border_width` attribute, which the X server draws *outside* a window's own declared width/height on all four sides - unlike every other backend's own border rendering in this compositor (Wayland's `decoration.rs`, ordinary pixels drawn *inside* the allocated geometry rect). `apply_geometry` configured the frame at `geometry`'s own x/y/width/height verbatim, so a nonzero native border pushed the frame's true, visible footprint `2 * border_width` past every edge of what `geometry` actually promised. + +Fixed by shifting the configured origin inward and the configured size down by `border_width` on both axes (`frame_geometry_for`, pulled out as a pure function the same way `modmask_for_keycode_in_mod_slots` already was, so it's unit-tested without a real X11 connection) - the *visible* footprint, native border included, now lands exactly on `geometry`, matching what every other border-drawing path already guarantees. `border_width == 0` (undecorated/CSD windows, the common case) reduces to exactly the prior behaviour. + +Full workspace build/test/clippy clean (13 x11 tests, up from 10). Not yet live-verified against a real X11 client on this machine specifically (aegis's own repro used `Xvfb :55` + a nested `srdwm --x11` + alacritty) - the fix is a direct, mechanical correction of confirmed-wrong arithmetic, not a guess, but flagged per this file's own standing policy of saying so plainly rather than implying more confidence than a fix actually has. + ## 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. |