Decided to try writing a Wayland compositor for fun.
-
Made interactive move work on touch (and resize too while I was at it), didn't need that many changes actually
Added a bit of rubberbanding before the window is "dragged out" of the layout. Should help avoid unintended layout changes.
Along with a few more fixes I did, I think interactive move should be good to merge? It's not 100% perfect and jank free, but I'm fairly sure I got all the important things done. Will give it some more testing.
-
Added a bit of rubberbanding before the window is "dragged out" of the layout. Should help avoid unintended layout changes.
Along with a few more fixes I did, I think interactive move should be good to merge? It's not 100% perfect and jank free, but I'm fairly sure I got all the important things done. Will give it some more testing.
Suddenly, @drakulix showcasing the Cosmic session running on, among other compositors, niri! On the big screen at the Ubuntu Summit
-
Suddenly, @drakulix showcasing the Cosmic session running on, among other compositors, niri! On the big screen at the Ubuntu Summit
somehow this touch moving under stationary pointer works better than i expected
(yes trying to do a precise left click with an elbow was difficult)
-
somehow this touch moving under stationary pointer works better than i expected
(yes trying to do a precise left click with an elbow was difficult)
By the way! I'll be giving a talk at RustCon in Moscow on December, 6!
Wherein I will briefly describe what a Wayland compositor is, and then show several testing and profiling workflows that I've been using to keep niri stable, robust and performant.
(The invitation to submit a talk was completely unexpected, guess niri found its way into the right eyes.
)There will be a recording, though in Russian.
-
By the way! I'll be giving a talk at RustCon in Moscow on December, 6!
Wherein I will briefly describe what a Wayland compositor is, and then show several testing and profiling workflows that I've been using to keep niri stable, robust and performant.
(The invitation to submit a talk was completely unexpected, guess niri found its way into the right eyes.
)There will be a recording, though in Russian.
Interactive window moving, laptop lid and tablet mode switch binds, mouse and touchpad scroll speed setting in today's niri v0.1.10 release!
https://github.com/YaLTeR/niri/releases/tag/v0.1.10
Also, niri-ipc is now on crates.io, but keep in mind that it will not be Rust-semver-stable: https://crates.io/crates/niri-ipc
-
Interactive window moving, laptop lid and tablet mode switch binds, mouse and touchpad scroll speed setting in today's niri v0.1.10 release!
https://github.com/YaLTeR/niri/releases/tag/v0.1.10
Also, niri-ipc is now on crates.io, but keep in mind that it will not be Rust-semver-stable: https://crates.io/crates/niri-ipc
Added scaffolding for layer rules, along with a block-out-from rule. Now you can finally block notifications from screencasts!
Though, layer-shell surfaces don't have a "geometry" so if they have shadows or transparent padding, all of that becomes solid black, since niri has no way to know where the "actual content" of the layer surface is (that's what geometry is for windows).
-
Added scaffolding for layer rules, along with a block-out-from rule. Now you can finally block notifications from screencasts!
Though, layer-shell surfaces don't have a "geometry" so if they have shadows or transparent padding, all of that becomes solid black, since niri has no way to know where the "actual content" of the layer surface is (that's what geometry is for windows).
We hit 4000 stars today on the niri repo!!
-
We hit 4000 stars today on the niri repo!!
Thanks to Christian Meissl's fix in Smithay, the git version of niri correctly shows nested pop-up menus in lxqt-panel. They also submitted a fix for invalid pop-up spawning to ironbar, which makes it work on Smithay compositors.
-
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
-
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
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?
-
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?
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
-
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
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.
-
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.
>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 -
>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 refactorThis 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.
-
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.
hmm
-
unusual sights
-
unusual sights
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.
-
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.
-
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.
-
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.
