srdwm - Cross-platform window manager written in Rust.

Age	Commit message (Collapse)	Author	Files	Lines
2025-08-15	Fix a dragged/resized window rendering wrong on a different-scale monitor ↵	srdusr	1	-0/+10
	mid-gesture Reported live: moving a window onto the other monitor "looks very messed up". This machine's two real monitors have genuinely different scales (eDP-1 at 1.0, HDMI-A-1 at ~0.843) - the exact condition needed to expose this. WindowManager::update_drag/update_resize only corrected w.monitor once, at end_drag (update_resize never corrected it at all, not even at the end) - but state/geometry.rs::sync_geometry reads that field on every motion tick to pick which monitor's scale converts the client's physical size into the logical points xdg_toplevel::configure sends it. Crossing onto a different-scale monitor mid-drag kept every configure computed against the origin monitor's stale scale for the gesture's whole remaining duration, only self-correcting once the button came up. Both functions now re-derive w.monitor from which monitor the window's live geometry actually overlaps, every motion tick - the same Rect::overlaps lookup end_drag already used once at the end, now run continuously instead. end_drag's own fixup stays as a final-word safety net for a drag that starts and ends between two motion ticks. Does not close the related, already-documented gap where a client that doesn't speak wp-fractional-scale-v1 still mismatches once settled on a sub-1.0-scaled monitor - this only fixes the stale-during-the-gesture half. Two new tests, full workspace suite and clippy clean.
2025-08-15	Add real desktop icons plus right-click desktop/icon context menus	srdusr	1	-2/+30
	Closes "right-click on bare desktop" - previously a true no-op, nothing rendered above the wallpaper at all. Requested directly: a real desktop "just like windows does" - Home/Computer/Trash plus one icon per real ~/Desktop entry, individually draggable with persisted grid positions, double-click to open, right-click menus (per-icon "Open" plus "Set as Wallpaper" for image files when general.wallpaper_command is set; bare desktop "New Folder"/"Refresh"). Architecture mirrors the existing context_menu.rs/snap_flyout.rs "compositor-owned floating UI" pattern: desktop_icons.rs (data model, grid layout, filesystem scan, hit-test), desktop_icons_state.rs (JSON persistence, same shape as monitor_layout.rs), desktop_menu.rs (the new right-click menu, reusing decoration::render_context_menu's existing rasterizer), state/desktop_icons.rs (CompState glue: rescan/select/drag/ open/persist), and a new decoration::render_desktop_icon rasterizer -- hand-drawn glyphs, since no PNG/SVG decoding capability exists anywhere in this workspace. Wired into both render loops (udev and winit) above the wallpaper and below every window, and into input/pointer.rs's button/ motion handlers for selection, drag, double-click, and both menus. Four new config keys: general.desktop_icons (default true - a directly requested, purely visual feature, unlike the opt-in-while-experimental general.gpu), general.file_manager, general.desktop_icon_single_click, general.wallpaper_command (all default off/empty). Deliberately out of scope for this pass, stated up front: move-to-trash and "Empty Trash" (destructive, no confirmation-dialog primitive to gate them on yet), filesystem watching, multi-select, per-mimetype icon art, icons on any monitor but the primary one. 124 wayland-crate tests (up from 106), full workspace build and clippy clean.
2025-08-13	Fix terminal content disappearing on resize: don't cache a blank content mask	srdusr	1	-0/+12
	Reported live: "terminal output/everything disappears when i sometimes resize terminal." masked_content_buffer (the udev/Pixman rounded-corner content-masking path, live on this machine via general.rounded_corners) rendered a window's whole surface tree into an off-screen buffer and returned Some(bytes) unconditionally, with no check for whether that tree actually produced any drawable elements. content_epoch bumps on every commit, and a fast interactive resize is a rapid-fire sequence of commits - real odds that one races ahead of the client's own texture import, making the off-screen render legitimately come back empty. That blank result got returned as Some and cached under the new epoch the same as a correct one would, and rounded_content_buffer only rebuilds on the next epoch change - so the blank buffer stayed on screen, fully transparent, until the window's next real content change, indefinite for an idle terminal. masked_content_buffer now returns None when the element tree is empty, before doing the render+readback at all - the same "give up unmasked" pattern already used for a genuine renderer error. rounded_content_buffer drops rather than replaces its cache entry on None, so the render loop falls back to unmasked content for that one frame and retries the masked path on the next. Scoped to the udev/Pixman backend; winit masks via a GLES shader with no equivalent failure mode.
2025-08-09	Fix interactive-resize border/shadow lag without the OOB risk that sank the ↵	srdusr	1	-3/+9
	first attempt effective_frame_of now returns the live drag target while a window is being interactively resized (same change as the reverted first attempt), but two things make it safe this time instead of reintroducing the out-of-bounds texture sample that reversion was for: - Every src crop rect built from a window's frame width in udev/render.rs and winit/render.rs (titlebar, top border strip, bottom border strip) is now clamped against DecorationSignature's own recorded width/ border_width - the bitmap's actual last-built size - before reaching MemoryRenderBufferRenderElement::from_buffer, which does not itself validate src against the real texture size. This is a structural floor independent of timing, not a repeat of the previous unsafe approach. - handle_pointer_position now calls redraw_decoration_buffer once per resize motion event (throttled to 60Hz via a new CompState::resize_redraw_at), closing the lag at its source instead of only catching up on the next real client commit. This also fixes the shadow bitmap's identical commit-vs-live-position gap for free, since redraw_decoration_buffer rebuilds all three bitmaps together. Updates the TODO.md entry for this bug with the full before/after.
2025-06-16	Add a minimal zwlr_foreign_toplevel activate test tool; confirm aegis's ↵	srdusr	1	-2/+8
	focus-staleness report no longer reproduces tools/toplevel-activate: a standalone (not a workspace member - its own empty [workspace] table, so building srdwm itself never has to build this too) wayland-client + wayland-protocols-wlr binary that lists every open zwlr_foreign_toplevel_handle_v1, activates one by index, and prints the resulting `activated` state from the protocol's own feedback. wayland-client 0.31.14 / wayland-protocols-wlr 0.3.12 - the exact versions smithay 0.7.0 already pulls in, so this talks to the same real client library srdwm itself is built against, not a possibly-drifted one. Used it to reproduce aegis's own exact repro (nested `srdwm --wayland`, two plain alacritty windows, activate the non-focused one, check `srd clients`) precisely: launched a real nested instance, activated back and forth 5 times, checked `srd clients` immediately and after a delay each time. Every check matched the protocol's own `activated` feedback - no staleness found, on the nested/winit backend specifically (the peer's own repro environment). Documented in docs/TODO.md as likely already fixed by other focus/window-management work since the original report, not re-root-caused after the fact, but confirmed not currently reproducible via the exact repro that found it - left open one more round in case it resurfaces, with this tool as the fastest way back to a live repro if it does.
2025-05-27	Document the investigation of aegis's focus-staleness report	srdusr	1	-0/+8
	Traced the whole write/read path for srd clients' focused field going stale after a zwlr_foreign_toplevel_handle_v1.activate-driven change -- ruled out several plausible causes (a caching/staleness bug at the IPC layer, a same-cycle dispatch-order race in the nested backend) without finding the actual mismatch. No live repro was run: this machine has neither pywayland nor wlrctl, and building a minimal wayland-client test binary to call activate directly is real, separate scope. Written up as a lead for whoever picks this back up, not a fix.
2025-02-15	Checkpoint: preserve all uncommitted rust-rewrite worktree work	srdusr	1	-0/+1596
	Safety commit before reconciling this worktree with main, which has diverged with its own separate fixes today. Nothing here is reviewed or curated yet - this exists purely so none of this work can be lost to a git operation, disk issue, or worktree cleanup while that reconciliation happens.