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-08-30T17:12:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-30T17:12:00+00:00 urn:sha1:bac91a6162542025676f57afc3e514b88aa65366 2026-08-30T15:53:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-30T15:53:00+00:00 urn:sha1:0d774d7cb79da990a252549dd6868ffac115ab7a 2026-08-30T15:39:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-30T15:39:00+00:00 urn:sha1:3d06793cdf7b44d380af6e9608c98d23ea193fa9 2026-08-28T15:01:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-28T15:01:00+00:00 urn:sha1:9e7dd09c41fa6c07d477877bb7f34f2913f1c49d 2026-08-25T12:49:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-25T12:49:00+00:00 urn:sha1:8b3ef3c7b28570122126a1c8b3d6695fc3647557 Two of the owner's reported gaps, both about moving a window without a mouse. Super+Shift+HJKL slammed the window to the far edge of the monitor in one press: "it should move in increments - one side, middle, other side - not just extreme left/up/right/down". It now steps an eighth of the monitor per press, which crosses the screen in eight, passes through the middle at the fourth, and stops flush against the edge rather than short of it. A fraction rather than a pixel count, so the same key feels the same on a laptop panel and a 4K display. Only outside a tiling layout. There a window does not own its geometry -- stepping it would be undone by the next arrange - so the neighbour swap stays, and three tests that assumed swapping on a dynamic workspace now say which layout they mean. Keyboard resize did not exist. Super+right-drag has resized with the mouse for a while, which is why this went unnoticed, but nothing resized a window without one. `srd.window.resize("right", "grow"|"shrink")` grows or shrinks from the far edge in that direction, leaving the top-left where it is, and is bounded by the same minimums a drag is and by the monitor's usable area - a window can be resized neither to nothing nor off the screen, and a test holds each key down forty times to prove it. Wired into the owner's config: Super+Ctrl+arrows resize (the arrow says which way the far edge moves, so Right always widens), and Super+Ctrl+L locks the screen. Hyprland only ever bound the lock to XF86ScreenSaver, which most keyboards do not have; Super+L is the convention everywhere else but is already focus-right here. Ctrl+arrows rather than Ctrl+HJKL because Super+Ctrl+K is already kill-process. Verified through the real path in a nested compositor running that config: 89 bindings, all 89 described, the five new ones registered. 2026-08-23T22:37:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-23T22:37:00+00:00 urn:sha1:807d0ba1680cdc1322bfe9584781416339f6f76d Reported: windows spawn predominantly on one side and on top of each other, with no smart placement. Measured first, in a nested compositor: five windows opened at 30,30 then 60,60 then 90,90 then 120,120 then 150,150 -- every pair overlapping, all in the top-left. The cascade was the only thing running. The grid never engaged, and could not. It asked whether a grid CELL was free and then placed the window at that cell's corner at its own, larger size. An ordinary 800x600 window on a 1280x800 screen overlaps every cell of a 2x2 grid, so no cell was ever free, the grid returned nothing, and everything fell through to the cascade. Placement now looks for a position where the window overlaps nothing at all, and only cascades when the screen genuinely cannot fit one - which is what Windows does once its own screen fills up, and what makes the cascade the right last resort rather than the first answer. The candidates are the edges of what is already on screen: every window's left and right edge plus the monitor's own, taken both as "put my left edge here" and "put my right edge here", and the same vertically. That is Openbox's place_overlap reduced to this case (~/reference-wms/openbox), and it works because a rectangle packed against other rectangles is always flush with one of their edges - nothing is gained by testing the space in between. Two things the naive version got wrong, both fixed here: Ties go to the position nearest the middle of the monitor, and the choice rotates through the four most central free spots. Least-overlap placement is deterministic, so opening one window at a time - open, use, close, open the next - put every one of them in exactly the same place, which is this project's own earlier bug report. Every candidate rotated between is free, so variety never costs the guarantee. And placement now runs again once the client's real size is known. It has to happen before the client commits anything, so it was deciding where an 800x600 placeholder should go rather than the window - a small terminal was told it was 800x600, no two of those fit, and it cascaded. Only when the client actually chooses a different size: re-running it otherwise consumed a second cascade step for nothing, and the cascade wraps, which measured as two windows landing on exactly the same spot. 287 core tests pass, clippy clean. 2026-08-21T17:24:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-21T17:24:00+00:00 urn:sha1:d440a3992e8a0fa49857210e646b0d653dfa7675 Inserting the title-elision helper directly above render_titlebar pushed that function away from its own #[allow(clippy::too_many_arguments)], which then applied to a const and left the function warning again. Third time I have done this to an attribute in this tree; the pattern is inserting at a "just before this function" anchor without checking what sits immediately above it. Also `"x".repeat(20_000)` in the new test, which clippy asked for. Clippy is clean again - and it was not when I said it was in the previous commit: the check printed its own "ok" line unconditionally, so three real warnings scrolled past above it. 2026-08-13T14:51:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-13T14:51:00+00:00 urn:sha1:f7426a86f2ccc40a18bc6b21d92fc3f073490de1 A title that did not fit was hard-cut at whatever character crossed the button reservation. Nothing marked the cut, so a truncated name read as the whole name - "annual-report-final-v7-reviewed-2026-with-appendix.ods - LibreO" looks like a filename, not like a filename with its tail missing. Titles now end in an ellipsis when they are shortened, which is what Windows, GNOME and KDE all do, and it keeps the informative half: an application or document title almost always begins distinctively and ends in boilerplate. Whole characters are dropped until the ellipsis fits beside what remains, so the result never overruns the buttons. A titlebar with no room even for the ellipsis draws nothing, rather than a lone "..." that says less than an empty titlebar does. The mark itself is "…" where the system font has that glyph and "..." where it does not. A missing glyph rasterizes to nothing at all, which would have quietly reintroduced the invisible-truncation problem on any font without it. Also bounded the work: a client may set a title of any length - a browser tab carrying a whole data URL - and every character cost a rasterization before the layout could decide it did not fit. Measurement stops at 256 characters, well past anything legible in a titlebar, and a title that long is elided many times over regardless. Four tests: an over-long title fits its span and ends in the ellipsis mark; a title that fits is left exactly alone; a titlebar too narrow for the ellipsis draws nothing; a 20,000-character title never lays out more than the cap. Checked on screen too, at 600px and at 220px.