Cross-platform window manager written in Rust. https://srdusr.com/git/srdwm/atom?h=main 2026-05-11T14:57:00+00:00 2026-05-11T14:57:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-05-11T14:57:00+00:00 urn:sha1:646b37e7e3aa5931079c6b9e804f420bb43c74d5 Four reports after restarting into today's build, with a screenshot. The screenshot was measured, not eyeballed: top bar y=0..29, a 4px accent border at y=30..33, titlebar from y=34, bottom border at y=1027..1030, and 49px of bare desktop below it. Windows spawning too close to the top bar. A remembered position was validated only by asking whether it landed on some monitor's full_geometry, which includes the strip a top bar reserves, so an app whose remembered y was small reopened with its titlebar under the bar. That is why it was "sometimes": it depended on the stored value, and the live store holds wezterm at y=44 and firefox at y=69 against a 30px bar. Remembered positions are now clamped into the monitor's usable area. Placement not surviving a logout. Window memory does persist, but five of the eleven entries in the live store were saved with a second monitor attached, at x >= 2000. Those points match no current monitor and were discarded outright, falling back to a fresh cascade, so those apps appeared to remember nothing. Such a position is now clamped onto a monitor that exists instead. Per-window minimum sizes. One global floor is wrong in both directions. Three sources now, in increasing precedence: the global floor, the client's own declared minimum (xdg_toplevel.set_min_size or ICCCM hints), and a min_width/min_height window rule overriding both. A rule wins permanently -- the backend refreshes the client's declared minimum on every decoration redraw and must not undo a deliberate override. Maximize, three faults in one report. A maximized window now draws no border: its edges are the screen's edges, and the only place maximize stops short is the bar strip, which is exactly where the measured line was. maximize_geometry_for no longer subtracts a bottom-anchored dock's exclusive zone, so maximize runs to the bottom of the screen and the dock floats over it; top, left and right are still honoured. general.maximize_covers_dock = false restores the old behaviour. With the border gone the window sits flush under the bar instead of with an accent line crowding it. Verified: seven new tests on the real numbers from the live store, and maximize geometry measured live in a nested instance (a window maximized on a split half reports exactly that half's rect). NOT confirmed on screen: the border removal and the dock behaviour - the nested backend has no bar or dock to reserve a zone, and an attempt to check the border produced a failing control, since srd set border_width only affects windows created after it. 515 tests pass, clippy clean. 2025-08-18T21:44:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2025-08-18T21:44:00+00:00 urn:sha1:d2af06d00e1b91bf9953e8c86eb30ab3ad9ee829 Reported live, in stages: general input sluggishness, then specifically dock/bar buttons not responding on the secondary monitor. Root-caused jointly with a peer session (dotfiles-16), who independently instrumented AGS itself (both bar and dock report correct visible/realized/revealed state - the client is asking for the right thing) and srdwm's own layer_hit_test log (the dock received zero hits across ~40 minutes while the same output's wallpaper and bar took hundreds). Confirmed against smithay 0.7.0's own source (desktop/wayland/layer.rs:: arrange): LayerMap::arrange() divides the output's physical mode by its own scale before arranging layers, so LayerMap::layer_geometry() is logical, not physical. Two call sites used it as physical, this compositor's convention everywhere else: - input/layers.rs::layer_surface_under_layers compared the physical pointer position directly against logical layer geometry. On a sub-1.0 scale output, logical space is larger than physical, so a bottom-anchored dock's rect sat entirely past the pointer's reachable range - permanently unclickable. A top-anchored bar only lost its own right-hand end, which is what made this look like "the dock is broken" rather than a scale bug affecting every layer surface there. - elements.rs::output_layer_elements pushed the same logical position straight into the physical framebuffer - for the dock, past the bottom edge entirely, painting nothing. Both fixed the same way udev/platform.rs::monitors() and udev/outputs.rs already fix the identical unit mismatch for usable-area computation (existing precedent, not a new technique): multiply by output. current_scale().fractional_scale(), rounding to the nearest physical pixel, before use. Also removed a temporary per-pointer-motion-event diagnostic log in layer_hit_test, still live from an earlier debugging session and explicitly marked for removal but never removed - a real, measurable cost on the hot input path, likely the direct cause of the separately reported general slowness. Full workspace test suite and clippy clean. 2025-02-15T12:56:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2025-02-15T12:56:00+00:00 urn:sha1:0a4c4b5941fe982ccb3d3175e26d9d83f0025ffd 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.