Decided to try writing a Wayland compositor for fun.
-
replied to Ivan Molodetskikh on last edited by
Somehow, a small change for tests escalated into trying to completely refactor how animation timing works in niri. And right now I find myself at the exact opposite of this picture. Unfortunately, time has not stopped and is causing problems
-
replied to Ivan Molodetskikh on last edited by
Like three complete refactors later, I think it's... working? For real this time? No weird issue is gonna sneak up that undermines the whole design?
-
replied to Ivan Molodetskikh on last edited by
Nothing seems to have caught on fire after one more day of personal testing and one more day in main. So here's a technical page I wrote about the the new niri animation timing design and its motivations: https://github.com/YaLTeR/niri/wiki/Animation-Timing
-
replied to Ivan Molodetskikh on last edited by
Today I merged a PR by FluxTape which adds "always empty workspace before first" to niri. At the surface this is just a simple config flag with obvious behavior, but it's actually full of edge cases! Things like which workspace to focus at startup. The code refers to workspaces by index in many places, and those all shift when you suddenly insert an empty workspace at index 0.
Took several days to catch them all even with our randomized tests, but I think it should be good now.
-
replied to Ivan Molodetskikh on last edited by
>did a +4,657 −4,237 refactor in the layout code
>while testing, already found two uncaught regressions introduced in previous niri releases, and no issues with the refactor -
replied to Ivan Molodetskikh on last edited by
This morning was my niri (-adjacent) talk!
Went really well, got many interesting questions!They promised us video recordings in a few days, so I'll post a link when I get it. Though of course the talk is in Russian.
-
replied to Ivan Molodetskikh on last edited by
hmm
-
replied to Ivan Molodetskikh on last edited by
unusual sights
-
replied to Ivan Molodetskikh on last edited by
Turns out, there's a lot of details to get right when implementing a floating window space. For example, dialog windows should always show above their parent window. Otherwise, it's easy to lose them under the (usually much bigger) parent.
The WIP floating branch in niri now handles this properly, even for xdg-desktop-portal dialogs (like file chooser) as long as the app correctly parents them via xdg-foreign.
-
replied to Ivan Molodetskikh on last edited by
Another piece of the floating puzzle: keeping windows on screen. When you change your monitor scale or resolution, you don't want your floating windows to suddenly go unreachable behind the monitor's new borders.
Here I'm resizing a nested niri with three windows, simulating resolution changes. No matter what I do, they always remain partially visible and reachable. Even for more unusual cases like trying to resize a window into out of bounds.
-
replied to Ivan Molodetskikh on last edited by
In the tiling layout, niri is constantly asking windows to assume their expected size. In contrast, floating windows should be able to freely change size as they see fit.
The logic turns out to be quite tricky. On the one hand we want a window to keep its latest size, but on the other we still want to be able to resize the window, which means asking it for a different size. The window can take a second to respond, or respond with a yet another size, and nothing must break.
-
replied to Ivan Molodetskikh on last edited by
While trying to make this work, I realized that this is the time when I *really really* want to be able to test this stuff. So I got on a sidetrack adventure to write testing infra for running real Wayland clients inside unit tests.
I've got it working! In these tests, I'm creating a new niri instance along with test clients, all on the same test-local event loop. No global state, no threads needed.
What's really cool is that this lets me test the weirdest client-server event timings.
-
replied to Ivan Molodetskikh on last edited by
This morning I worked on remembering the size for floating windows when they go to the tiling layout and back.
The whole sizing code must be at the top by logic complexity in niri. I have to juggle, all at once:
- new size I haven't sent to the window yet,
- size changes I sent, but window hasn't acked yet (0, 1, or more in-flight),
- size change window acked but hasn't committed for yet,
- size change window acked and responded to with a commit (maybe with a different size entirely). -
replied to Ivan Molodetskikh on last edited by
The diff is 85 lines of change and 243 lines of new tests, and I already found a few weirder edge cases that I've missed. No way I could do this well without that client-server testing setup that I posted about yesterday.
Btw I pushed the testing setup if you're curious, along with the entirety of 1215 snapshot files for a powerset of new window workspace/output target settings: https://github.com/YaLTeR/niri/commit/771ea1e81557ffe7af9cbdbec161601575b64d81
The WIP floating branch caused them to update in several commits already.
-
replied to Ivan Molodetskikh on last edited by
The big 1215 snapshot test powerset (actually it already grew to 1695) continues to prove its worth. Just finished a big +495 -508 cleanup of the window opening code, and verified that not a single of those 1215 window opening configurations changed its outcome. I will be sleeping well tonight
-
replied to Ivan Molodetskikh on last edited by
After three weeks of hard work, I am undrafting the floating window PR in niri. Please give it thorough testing and report any bugs or issues!
-
replied to Ivan Molodetskikh on last edited by
-
replied to Ivan Molodetskikh on last edited by
-
replied to Ivan Molodetskikh on last edited by
Alright, I think I got all of the important things in for the next niri release. Today I updated Smithay for the DRM compositor changes, and added a workaround for a panic when you have two monitors with exactly matching make/model/serial.
I'll give it a week of testing (if you run niri-git, please report any problems) and if all goes well, tag next Saturday.
There are a few PRs I'll try to review in time, but they're fairly self contained.
-
replied to Ivan Molodetskikh on last edited by
After a full day of writing release notes (god how'd it take so long
), niri v25.01 is out with Floating Windows and Working Layer-Shell Desktop Icons and Layer-Shell Screencast Blocking Out and so many more improvements! Yes, you read that right, we finally escaped zerover! I feel that niri is now ready to graduate from v0.1 Read here and download when your distribution package updates: https://github.com/YaLTeR/niri/releases/tag/v25.01
