Cross-platform window manager written in Rust. https://srdusr.com/git/srdwm/atom?h=main 2026-04-19T22:48:00+00:00 2026-04-19T22:48:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-04-19T22:48:00+00:00 urn:sha1:436d42da6ef61a5ea20d5102c4baed7bf0993606 Nemo's right-click context menu was the last open punch-list item, parked twice as untestable. It works: verified end to end in a throwaway nested compositor, menu and submenu both, at the correct position and stacking. The popup path itself needed no fix, so the POPUP-GEOM-DIAG/POPUP-GRAB-DIAG diagnostics are removed. Two real bugs turned up in the way of testing it. zwlr_virtual_pointer was a silent no-op on the winit backend. Every Motion/MotionAbsolute handler read UdevState::bounds() behind an early return when state.udev was None, and that field is Some only for the DRM backend. The protocol advertised its global, accepted create_virtual_pointer and accepted every request, then discarded all motion with no error and no log. That is the backend a nested instance runs on, so the only safe way to drive a throwaway compositor - a Wayland client of that compositor, which cannot reach any other session, unlike ydotool's /dev/uinput writes - did not work at all. Bounds now come from WindowManager::monitors() when udev is absent; both backends fill that list from Platform::monitors(). The winit backend's screencopy pass rendered no popups and no shadows. It re-renders the scene offscreen, and that second scene was missing tiers, so grim on a nested instance reported the opposite of the truth: a menu drawing perfectly on screen photographed as absent. The DRM backend never had this, since it serves screencopy from the on-screen frame it just drew. Border strips are still missing from that pass, called out in the code rather than left silent. Also fixed, from the "windows show a bit in the other monitor" report: shadow_rect expanded by SHADOW_SIZE on every side with no monitor-boundary awareness, so a window flush against a seam put its 24px shadow strip on the neighbouring screen. shadow_rect_clipped clips to the bounding box of the monitors the window's geometry actually touches - not just its assigned one, since a window straddling a seam really does occupy both and clipping there would cut its shadow off mid-body. The bitmap's own extent stays unclipped, because the src rectangle indexes into it; only the fragment list is clipped. Six tests on the incident's own numbers. Not confirmed on screen: the nested backend cannot produce a second monitor. New tool: tools/virtual-pointer-click, a scriptable virtual-pointer driver that acknowledges each command after its round-trip, so a test script can put a screenshot between a move and the click that follows it. 489 tests pass, clippy clean. 2025-09-11T18:46:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2025-09-11T18:46:00+00:00 urn:sha1:b219797e2143ea84cf527fbf48afb22cc35fe9a5 Standalone (not a workspace member, same reasoning as the existing tools/toplevel-activate), built to live-verify the Wayland crate's new pinned-virtual-pointer delivery (crates/wayland/src/virtual_pointer.rs) against a real client rather than reading the source: prints its own pid so an external script can pin it via srd dispatch pin input, then drags from one point to another on a stdin signal. Not yet run against a live nested instance - launching one hits this project's own nightshift deny-list guard against a bare nested-compositor invocation, parked rather than worked around; see docs/TODO.md. 2025-06-16T21:40:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2025-06-16T21:40:00+00:00 urn:sha1:5f26a48fbb772ccc9c9ffb1209ff00d3c11d88c7 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.