Cross-platform window manager written in Rust. https://srdusr.com/git/srdwm/atom?h=main 2026-08-30T19:15:00+00:00 2026-08-30T19:15:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-30T19:15:00+00:00 urn:sha1:9a7f30050f8efc52340e698031a7a55a105e72c4 2026-08-30T18:41:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-30T18:41:00+00:00 urn:sha1:f2f9ed1b3f9c49b323ce591eb72a406058d324a4 2026-07-07T21:32:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-07T21:32:00+00:00 urn:sha1:a6f98eba60f71f7250f4383e76642a901c5b8439 Three reports, three separate causes. Alternate characters were invisible. A keycap drew only the character the current shift state types, so there was no way to find a symbol without pressing Shift and hunting for it - a physical key is labelled with both. Each cap now draws the other state's character small and dimmed in its top-right, skipped where the two are the same (every letter differs only by case, which the cap already shows) and for named keys like Enter. "Enter Password" rendered in a monospace font. find_system_font deliberately prefers a mono face, which is right for a titlebar title or a menu row sitting in columns and wrong for a sentence; on this machine it resolves to DejaVu Sans Mono. New find_ui_font prefers a proportional face from a ranked list of widely-installed families, falling back to the mono one, and the lock screen's prose - prompt, clock, date, username, status -- uses it. Ranked rather than first-found so the result does not depend on directory order, which is how the mono scan once picked an italic face and rendered every titlebar in italic. The password dots had no spacing. They were drawn as a plain string, so a run of identical bullets separated only by their own advance read as one smeared blob rather than countable characters. Added explicit tracking, excluded from the centring width so the row does not sit half a gap left. 531 tests pass, clippy clean. 2026-07-04T12:22:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-04T12:22:00+00:00 urn:sha1:d448a82990efb5c510064f1de5b5d32e932a4f9e Two gaps, both found by being asked about them. ~/.face was never read. The file exists here, a 300x300 JPEG, and a grep for .face/AccountsService/avatar_path returned nothing anywhere in the codebase: the lock screen drew a coloured circle with the user's initial unconditionally. It now looks for ~/.face, ~/.face.icon, then /var/lib/AccountsService/icons/$USER, which is where GNOME and KDE keep the picture their settings UI sets. Scaled to cover the circle and centre-cropped rather than letterboxed, and masked with a soft edge. Falls back to the initial when nothing is set or the file will not decode. That needed a raster decoder, since ~/.face is JPEG and the only image code here was resvg, which is SVG-only. Added image with default features off and only jpeg and png. The on-screen keyboard could not type most passwords. It had letters, digits, and the digits' own shifted symbols, and nothing else - no -, _, ., /, =, [, ], ;, ', comma, backslash or backtick. For the case that keyboard exists for, a session with no reachable physical keyboard, a password containing any of those meant no way in at all. Every printable ASCII character now has a key, with a test asserting the whole 0x20..0x7f range rather than spot-checking. The lock screen itself could not be screenshotted: locking a nested instance hits the pre-existing EGL context-loss crash already recorded in docs/TODO.md, confirmed again here. That is environmental and predates this change, so the on-screen appearance still needs the real session. The avatar path is covered by four tests including one that decodes the real ~/.face through the same function the lock screen calls. 529 tests pass, clippy clean. 2026-05-11T14:44:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-05-11T14:44:00+00:00 urn:sha1:caec1e7c355bbe6437afe87cd3dab6b64fb91e0a All three reported directly after the owner restarted into today's build. Desktop icons could not be dragged at all in single-click mode. The press handler opened the icon immediately when general.desktop_icon_single_click was on, so the branch that starts a drag was unreachable and an icon could never be moved. Deciding activation on press cannot distinguish a click from the first instant of a drag. Every press on an icon now starts a potential drag and release decides which it was, using a 4px movement threshold that latches once exceeded. Double-click mode goes through the same path, so both modes now drag identically. The lock screen drew no cursor. The cursor push in the udev render loop sits inside `if !locked`, and a locked head renders only the lock element list, so nothing drew a pointer - and on a bare TTY nothing else does. The on-screen keyboard's clicks were being handled correctly the whole time (native_lock_click); they simply could not be aimed. The pointer is now prepended to the lock element list, above the UI it is used to click. The password field's opaque panel is gone. New LockConfig::box_opacity, default 0.0: no fill, no border, no rounded rectangle, just the dots and status text over the blurred background. Raising it restores the panel at that opacity for anyone who wants a solid field. Drawing text on a transparent surface needed a new blit_glyph_over: the existing blit_glyph blends against one flat opaque colour and writes alpha 255, which would have turned every glyph into a block of the assumed background - the same box with its middle removed. VERIFICATION STATUS, stated plainly: all three are code-complete and the suite passes, but none is confirmed on screen. The nested backend's capture pass does not draw the desktop icon grid (a gap already recorded in winit/capture.rs), so the icon drag cannot be checked by screenshot there, and aiming blind is what this project's own rules forbid. The two lock changes were not visually checked either. 515 tests pass, clippy clean. 2025-11-20T15:10:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2025-11-20T15:10:00+00:00 urn:sha1:ae47a562bd423df856ec6c735d9e4c29a8e1e3c6 The native lock UI was a flat bordered rectangle with three left-aligned text lines and no shadow, clock, or identity marker - reported directly as looking unfinished. Splits the redesign across a new transparent-canvas header (time, date, circular avatar, username) above a redesigned, centered password box with a real drop shadow and a dimmed placeholder prompt, plus a genuine on-screen QWERTY-shaped keyboard with working Shift/Backspace/Return/Space and real click hit-testing shared with the render path via one `lock_stack_layout` function, and a damped-sine shake on a failed attempt. LockConfig gains show_clock/show_keyboard/avatar_bg, each independently srd.set-able and documented in a new theme.lock.* section in DEFAULTS.md. native_lock_render_elements now takes one NativeLockFrame struct instead of positional buffer arguments now that it composites five optional layers instead of two. Full workspace build/test/clippy clean (152 wayland tests, +6 new). 2025-04-03T20:35:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2025-04-03T20:35:00+00:00 urn:sha1:254557f94544fe8841a4e9422eee9228e7ed4152 round_top_corners/round_bottom_corners only ever cut pixels *outside* the shared corner radius (the rounded outer silhouette). Nothing cut anything *inside* it, so a border strip's own "extra" rows (present whenever corner_radius > border_width) stayed a solid filled disk out to the centre column/row, then hit clip_middle_beyond_thickness's hard, unblended rectangular cut right at the disk's own most opaque point - a clean right-angle step, not a curve. Confirmed live, zoomed: a real square notch bitten into an otherwise smooth arc, reported as "squares on the inside corners of each vertex." Added carve_inner_corner_pixel, the same smoothstep falloff as the existing outer cut but inverted (cuts near the centre instead of far from it), applied at radius - border_width so the corner becomes a genuine ring of ~border_width visible thickness tapering smoothly to transparent, instead of a filled wedge. Only render_border_top/ render_border_bottom pass an inner_radius; the titlebar's own corner and the lock-screen box keep their existing solid-disk behaviour, which is correct for a single flat-coloured panel with nothing of a different colour underneath needing to show through. Also generalizes round_top_corners with an explicit center_col parameter, mirroring the existing center_row shift: the titlebar's own corner circle was never shifted horizontally to match the border strip's (only vertically), leaving a border_width-wide sliver of the titlebar's own misaligned curve poking through at the seam. border_top_and_titlebar_corners_meet_without_a_seam and border_top_curve_actually_closes_within_the_side_strips_own_width updated to match: both now compare the correct corresponding columns (the titlebar's own buffer starts border_width columns inside the border strip's), and the latter no longer demands exact 255 opacity at a point that legitimately sits within the new inner cut's own antialiasing band. 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. 2024-10-30T21:52:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2024-10-30T21:52:00+00:00 urn:sha1:9748bca006cd2498c4c0f2730d8789c667bda52b A real ext-session-lock-v1 implementation drawn by the compositor itself, not a hand-off to an external locker process: a live-blurred background, PAM authentication on a background thread, and its own config surface (lock_config.rs) rather than hardcoded appearance.