Cross-platform window manager written in Rust. https://srdusr.com/git/srdwm/atom?h=main 2026-08-30T18:41:00+00:00 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-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-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. 2026-07-15T14:37:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-15T14:37:00+00:00 urn:sha1:0091bcd39406d88ceb075f03de4f3bfe12fed316 Reported as the titlebar not resizing at the same time as the window, and as resizing feeling cheap. effective_frame_of returned the live drag target while a resize was active, so the titlebar and border tracked the pointer while the client's actual pixels were still whatever it last committed. The two disagreed for the whole drag, and the decoration leading its own content is what reads as broken. It now returns the committed size anchored to whichever edge the drag is holding still - exactly the rect the content occupies, since sync_geometry positions it the same way, so the two agree by construction rather than by timing. The consequence is that the frame sits one commit behind the pointer instead of ahead of its own content. That is the trade every other compositor makes, and it is the right way round: a frame glued to its content and slightly behind the cursor reads as solid. The committed-size correction was extracted into committed_frame so the resize path and the ordinary path share it rather than having two versions that can drift, and so the resize path is no longer short-circuited by the pending-configure branch, which fires constantly during a drag precisely because every tick sends a configure. 533 tests pass, clippy clean. The arithmetic is covered where it is testable; how it feels mid-drag is a judgement only real hardware can make, and a nested drag did not reproduce a clean enough scenario to claim it. 2026-07-14T20:34:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-07-14T20:34:00+00:00 urn:sha1:aa7b7278b9e758985197170bcee4f0d2d4cb4590 Two things, and the first is smaller than I told anyone. WORKSPACE CAPTURE. I said off-screen workspace capture did not exist and would need building. It already did: udev/capture.rs renders a workspace that is not on screen, at the target monitor's native size, downscaled to a requested size, wallpaper included. Verified on the live DRM session rather than from the source - capturing the active workspace and a non-visible one gave 320x180 images with mean luminance 0.067 and 0.137, so the second is genuinely a different render and not a copy of what is presented. The only thing missing was the container. It wrote PPM, which the shells that want thumbnails cannot decode, so the file was written successfully, returned successfully, and silently not drawn - the same failure class as a capture pass that omits a tier. encode_capture now picks the format from the destination's extension: .ppm still writes PPM so existing callers keep working, .jpg/.jpeg write JPEG, anything else writes PNG. Four tests check the actual magic bytes rather than trusting the call, plus the unfamiliar extension fallback and a size-mismatch error. LEFT-EDGE RESIZE. Reported as content resizing "from the right side even when i resize from left". The window's origin moves the instant the pointer does, but the client only commits a matching buffer some frames later, so its still-old content was being placed at the new origin - which slides the whole window rather than growing it, and leaves the edge that should be nailed down drifting. sync_geometry now derives the origin from the size the client has actually committed when the drag is from a left or top edge, so the opposite edge stays exactly where the drag started and the dragged edge catches up as commits arrive. A right or bottom drag is untouched: its origin never moves. 533 tests pass, clippy clean. 2026-06-02T18:08:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-06-02T18:08:00+00:00 urn:sha1:30d45a7b9e0ddcd7ed2836c16e77b423cf3cff28 Two reports, both traced to a cause other than the one being blamed. "Windows still spawn as squares" was not placement. On the live session firefox was 800x632 and so were four other apps, and 800x632 is exactly the placeholder new_managed_window assigns before a client has chosen anything. Firefox's remembered size earlier the same day was 1389x933. The loop: a window closes while still carrying the placeholder, the placeholder is remembered, the next launch therefore has a remembered size and is no longer provisional, a non-provisional window is forced to its size instead of being asked to pick, and on close the placeholder is written back. Every app that ever closed early gets pinned to one identical box, and no amount of placement work can touch it because the size never came from placement. remove_window now refuses to remember a size the client never chose. That alone would have been wrong: adopt_provisional_size cleared its own tracking set but never cleared Window::size_is_provisional, so nothing would ever have been remembered again. Both halves are covered by tests. Five poisoned entries were dropped from the live store and the six real ones kept, with a backup alongside it. "When user sets decorations should override all applications": the earlier answer was true about the protocol and wrong about the outcome. GTK never negotiates decoration, but it does read the desktop's button-layout preference - GTK4 through xdg-desktop-portal, GTK3 through gtk-decoration-layout. srdwm now publishes its own button_side there at startup and after every reload, which is precisely the job kde-gtk-config does for KWin. Verified in both directions from a neutral starting value; testing the second direction is what exposed an ordering bug where the publish ran before apply_general_settings and broadcast the default instead of the configured side. 527 tests pass, clippy clean. 2026-05-15T17:05:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-05-15T17:05:00+00:00 urn:sha1:27daed83230eaefd0f41461cad20bbed7d1ad575 The maximize border was still drawn because the earlier fix landed on the wrong branch. udev/render.rs has three border blocks: the SRDWM_GPU=1 path at the top and two Pixman ones below. The patch replaced the first match in the file, which is the GPU branch a real DRM session never runs. All four sites across both backends are now gated on !maximized. The verification had failed twice for a separate reason: winit/capture.rs did not draw border strips at all, so a screenshot could never answer "is there a border here" and the control passed for the wrong reason. Border strips are now drawn into that pass as solid fills - corner rounding is not reproduced, so a capture is not pixel-exact at the corners, but presence, position, thickness and colour are. With that closed the test has a real control: unmaximized gives 6 accent pixels at x=800..805, exactly the configured border_width, and maximized gives none at the right edge or along the top row. That proves the winit path; the Pixman path is the same change at two more sites and is not separately confirmed on screen. Windows spawning as squares, partly off-screen, and always on the left were all SmartPlacement::grid. It returned size.min(cell), shrinking every window to its grid cell whatever size it asked for; it scanned cells in reading order and took the first free one, which is the leftmost; and nothing clamped the result, so a window larger than its cell could hang off the edge with its border out of view. The cell now decides only where a window goes, the scan starts from a rotating cell, and both grid and cascade clamp into the usable area. Four tests, one per reported symptom. 525 tests pass, clippy clean.