This morning was my niri (-adjacent) talk! :ablobcatbongo: 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.
Top-level
This morning was my niri (-adjacent) talk! :ablobcatbongo: 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. 12 comments
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. 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. 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. 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. 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 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! No video yet (soon tm) but my talk got rated first among all 9 Moscow RustCon talks :blobcat: And they uploaded photos from the conference. Sidenote, for the Wayland diagram from the first pic, I took inspiration from @drakulix's one from her great "Why YOU should write a Wayland compositor" talk: https://youtu.be/FUif2GxwgBc Definitely check it out! |
hmm
#niri