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-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. 2026-08-10T23:35:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-10T23:35:00+00:00 urn:sha1:38d899d19b5e5204062ecab4bb4105d51afddb6b Reported twice, as two complaints: windows do not remember their size or position across a close or a reboot, and windows spawn stacked on one side with no smart placement. One bug. `add_window` looks the store up by app_id. A Wayland toplevel role exists before its client sends set_app_id, so at the moment srdwm placed a window the app_id was the empty string, every lookup missed, and every window fell through to the cascade - which is exactly what "they all open on top of each other" looks like. The store was being written correctly the whole time and read at the one moment it could not match. The lookup now runs again the instant a real app_id arrives, which is still before the client's first buffer, so nothing is drawn in the wrong place first. It only moves a window still sitting where the cascade put it: a rule's explicit geometry, a maximize, a dialog's centring and a client's own committed size are each more specific than "wherever I last left this app", and a test asserts none of them is overridden. A second bug sat underneath the first and only appeared once it was fixed: the position came back and the size did not, which is stranger than nothing being restored. The backend keeps its own copy of "this size is only a guess" (provisional_size) and adopt_provisional_size reads that one rather than the core flag, so the client's next commit overwrote the size that had just been restored. Cleared with the same call. Verified end to end in a nested compositor, driving a real edge-drag with the virtual-pointer tool: seeded store 400,300 500x400 -> opened at exactly 400,300 500x400 dragged the right edge -> 646 wide, store rewritten to 646 on release closed and reopened -> 400,300 646x400 Before this the same first step opened at 30,30 800x600. Also: window_memory::save_all's nested guard now allows a write when the instance was given its own state directory (SRDWM_STATE_PATH or XDG_STATE_HOME). The blanket refusal added earlier kept the owner's store safe but made the feature impossible to test without pointing a test compositor at the real desktop, which is how this went unverified in the first place. 2026-07-26T23:33:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-26T23:33:00+00:00 urn:sha1:3c47912ae0a2b81d06e4e9101b5b4e2f1e2997d9 Two findings from reading what other projects do, and then measuring this machine rather than trusting the reading. GTK has never implemented xdg-decoration, so a compositor that advertises only that protocol is invisible to every GTK client on the decoration question. What GTK does implement is KDE's older org_kde_kwin_server_decoration - confirmed by reading libgtk-4's own symbol strings, where the manager, the mode enum and the default-mode handler are all present, and absent from libgtk-3. That is the channel a KDE session uses. srdwm now advertises it alongside xdg-decoration, with both answering from the same policy (theme.default_decorated, theme.force_server_side) so a client is told the same thing whichever it asks through. Measured what that actually buys, with WAYLAND_DEBUG on a real GTK4 client: it binds the manager and receives default_mode(2) = Server, and then never creates a decoration object for its window. So it changes nothing for a GTK application's own header bar, and it is kept because it is the correct thing to advertise and because clients that do honour it - Qt and KDE's own -- now get server-side decoration from srdwm instead of nothing. The second finding is the one that fixes what was reported. GTK3 and GTK4 put their window buttons under different CSS selectors, and the generated stylesheet named only GTK3's. A diagnostic rule proved it both ways: a flat colour reached Nemo (GTK3) through `headerbar button.titlebutton` and gnome-calculator (GTK4) through `windowcontrols button`, and neither selector reached the other toolkit. Every style is now written for both, so a GTK4 application is styled rather than silently skipped. `headerbar` itself works in both, so the titlebar block needed no split. Verified on screen: gnome-calculator, a GTK4/libadwaita application, now draws its header bar in srdwm's own titlebar colour with srdwm's text colour, where before it kept its theme's. Also worth writing down, because it bounds what any of this can achieve: an application's header bar is its own widget. No protocol removes it. GTK_CSD=0 does not, the KDE protocol does not, and neither does forcing server-side decoration - that only adds a second titlebar above the first. What a compositor can do is make the two look like one, which is what this does. 2026-07-26T23:25:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-26T23:25:00+00:00 urn:sha1:e20d49b0ee3dbd83499445d61eb2d65904d74311 Regression I introduced two commits ago, reported live: "I can click close where the button would normally be and it does close, but it is still invisible." The gate that stops an empty frame being drawn before a client paints asked the renderer, from inside the render loop, whether a window's surface had a buffer attached right now - and treated "no" as "do not draw". That question is only meaningful for a native xdg-shell toplevel. An XWayland window's surface state does not describe it the same way, so the answer came back no on every frame and the window was never drawn again, while srdwm's own hit-testing carried on working perfectly: an invisible window that still takes clicks, which is a worse failure than the empty frame it was meant to prevent. Inverted to the fail-safe direction. `new_managed_window` - the one path that creates a native toplevel - puts the window into `awaiting_first_buffer`, and `commit` takes it out on the first commit that carries a buffer. The render and capture paths test that set and nothing else. A window is now hidden only when srdwm itself put it there, so no window whose plumbing works differently can be hidden by a lookup that did not apply to it: the XWayland map path never touches the set, and neither can anything else. The buffer question still gets asked, but only in `commit`, about a surface it was just handed, where it is the right question. Verified both halves: an ordinary spawn still shows no frame before content (26 captured frames with content, 0 without), and the only way into the set is one line in one function. 2026-07-26T21:02:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-26T21:02:00+00:00 urn:sha1:492aa5b554ddc389bb2f233c60ea503b3dbda990 Reported live: "resizing shrinks/grows only the right side", and "the titlebar seems separate when resizing, it doesn't size at the same time". Both are one bug. Every decoration - border strips, titlebar, shadow -- is drawn from `frame`: the client's last committed size, anchored to whichever edge the drag is not holding. The content was drawn from `geom`: this compositor's live drag target, which moves on the same frame the pointer does. A client is always at least one commit behind a drag, so for that whole interval the two rects disagree, and the window is drawn as two pieces that move independently - the stale buffer sliding left with the pointer, carrying its old width, while the border it belongs in stays where the committed size puts it. Dragging a left edge therefore looked like it moved the right one. All three content paths now position from `frame` (both udev render loops and the winit one). Outside a resize this changes nothing at all: `committed_frame` only ever corrects the far edge, so `frame.x`/`frame.y` and `geom.x`/`geom.y` are the same value. Measured in a nested compositor, driving a real left-edge drag with the virtual-pointer tool and sampling both the model's target rect and the rendered pixels at the same moments: the content sits exactly one border width inside the border on both sides in every frame, the right edge holds at 830 throughout, and the left edge tracks the pointer (305, then 405). The earlier decorated-window run measured the same thing for the titlebar: its left edge moved with the window, its right edge did not move at all. 2026-07-23T20:56:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-23T20:56:00+00:00 urn:sha1:8ed79c21a53e10c29ea35b9a605250ea18f191cf Reported as "before a window spawns, the border corners look funny". A toplevel is placed, sized and decorated the moment its role is created, which is well before the client draws. srdwm was rendering it from that moment, so what appeared first was an empty frame: border, titlebar and shadow standing around bare desktop, at the guessed 800x600 placeholder size, with nothing inside. When the real buffer arrived the frame snapped to the real size. Measured in a nested session, capturing a cold terminal's spawn with grim: four consecutive captured frames spanning 540ms showed a complete red border with zero client content inside it, at 642px outer height, which then settled at 610 - a jump of exactly one TITLEBAR_HEIGHT. After this change the same capture has no such frame at all: every frame that shows a border shows content in it, and the height does not change afterward. Two parts: - Nothing is drawn for a window that has never committed a buffer. All five paths that draw a frame agree on this - both udev render loops (Pixman and GPU), the winit render loop, and both screencopy paths, so a screenshot cannot show a frame the screen does not. - The open-slide starts at the first commit that carries a buffer rather than at role creation. A cold terminal took ~800ms to paint, long enough for the whole tween to finish against the empty frame, so the window simply appeared, already at rest, with no animation at all. It now animates where it can actually be seen. The answer latches once true (windows_shown_once), so a window that has legitimately shown something is never hidden again by this however its buffer state changes. A window that cannot be resolved to a surface counts as drawable, deliberately: this hides a window only on positive evidence that it has never drawn, so nothing whose surface plumbing works differently - an XWayland window - can be hidden by a lookup that did not apply to it. Same shape, and the same reason, as sync_layer_visibility's own has_buffer branch, which layer surfaces have had all along. 533 tests pass, clippy clean.