Decided to try writing a Wayland compositor for fun.
-
We've hit 15k stars on the niri repo!!
Just merged Alt-Tab to main, shortly arriving at your nearest niri-git. Comes with plenty of ways to tweak it if you want [1], and a focus timestamp in the IPC [2] that lets shell devs make their own recent windows switchers.
[1]: https://yalter.github.io/niri/Configuration%3A-Recent-Windows.html
[2]: https://yalter.github.io/niri/niri_ipc/struct.Window.html#structfield.focus_timestamp -
Just merged Alt-Tab to main, shortly arriving at your nearest niri-git. Comes with plenty of ways to tweak it if you want [1], and a focus timestamp in the IPC [2] that lets shell devs make their own recent windows switchers.
[1]: https://yalter.github.io/niri/Configuration%3A-Recent-Windows.html
[2]: https://yalter.github.io/niri/niri_ipc/struct.Window.html#structfield.focus_timestampDid some work on the TTY backend in niri over the past few days. Merged PR for DisplayLink dock support, added "panel orientation" property read, and, based on cosmic-comp code, implemented the necessary logic to avoid screen blanking. Finally, both at niri startup and when switching TTYs, your screen won't flicker, as long as resolution/refresh rate stay the same.
Even when the screen does blank, it'll go faster, as there's now just one modeset instead of two (clear then draw frame).
-
Did some work on the TTY backend in niri over the past few days. Merged PR for DisplayLink dock support, added "panel orientation" property read, and, based on cosmic-comp code, implemented the necessary logic to avoid screen blanking. Finally, both at niri startup and when switching TTYs, your screen won't flicker, as long as resolution/refresh rate stay the same.
Even when the screen does blank, it'll go faster, as there's now just one modeset instead of two (clear then draw frame).
Took some fighting but I think I've managed to teach the new Alt-Tab to speak to the screen reader
-
Took some fighting but I think I've managed to teach the new Alt-Tab to speak to the screen reader
I finished and merged the horizontal drag interaction tweak from a previous post. It's very handy but can also be annoying when you want to move windows across monitors, so on mouse I restricted it to headerbar dragging (so, not Mod+LMB and not in the overview).
On touch however, it works for both headerbar dragging, and for Mod+Touch, so you can now easily scroll the view around.
I also added the thing where you can touch with another finger to switch between floating and tiling.
-
I finished and merged the horizontal drag interaction tweak from a previous post. It's very handy but can also be annoying when you want to move windows across monitors, so on mouse I restricted it to headerbar dragging (so, not Mod+LMB and not in the overview).
On touch however, it works for both headerbar dragging, and for Mod+Touch, so you can now easily scroll the view around.
I also added the thing where you can touch with another finger to switch between floating and tiling.
DankMaterialShell folks set up builds for Debian, Ubuntu and OpenSUSE, so now it's super easy to try niri & DMS on those systems.
I added Ubuntu commands to the niri quick start guide: https://yalter.github.io/niri/Getting-Started.html
Debian and OpenSUSE here: https://build.opensuse.org/project/show/home:AvengeMedia:danklinux
-
DankMaterialShell folks set up builds for Debian, Ubuntu and OpenSUSE, so now it's super easy to try niri & DMS on those systems.
I added Ubuntu commands to the niri quick start guide: https://yalter.github.io/niri/Getting-Started.html
Debian and OpenSUSE here: https://build.opensuse.org/project/show/home:AvengeMedia:danklinux
Today I'm releasing niri v25.11 with long-awaited config includes, Alt-Tab, true maximize, custom modes, and a bunch of other improvements!
Enjoy the release notes 
-
Today I'm releasing niri v25.11 with long-awaited config includes, Alt-Tab, true maximize, custom modes, and a bunch of other improvements!
Enjoy the release notes Congrats sternenseemann on the nixpkgs niri any% WR at 3 h 20 min
-
Congrats sternenseemann on the nixpkgs niri any% WR at 3 h 20 min
funny how while working on alt-tab i discovered that mouse scrolling on top of the DMS bar switches workspaces, which completely replaced any need i had for alt-tab, so i ended up never using it
this DMS bar scrolling feature also removed one of my main usecases for the overview
and then the new horizontal window drag gesture removed my other main usecase for the overview, so now i'm opening the overview quite rarely too
(both have their uses; just curious to watch my own habits shift)
-
funny how while working on alt-tab i discovered that mouse scrolling on top of the DMS bar switches workspaces, which completely replaced any need i had for alt-tab, so i ended up never using it
this DMS bar scrolling feature also removed one of my main usecases for the overview
and then the new horizontal window drag gesture removed my other main usecase for the overview, so now i'm opening the overview quite rarely too
(both have their uses; just curious to watch my own habits shift)
I've had one of those sessions today where I worked with a ton of random windows on a long workspace, while preparing slides for a uni scientific presentation. All kinds of various PDFs, file managers, InkScape, GIMP and so on.
Horizontal mouse headerbar drag to scroll the view was a lifesaver. Definitely a good choice adding this. Along with scrolling the view on DnD near the screen edge. Going through the overview, or always through the keyboard, would be very annoying.
-
I've had one of those sessions today where I worked with a ton of random windows on a long workspace, while preparing slides for a uni scientific presentation. All kinds of various PDFs, file managers, InkScape, GIMP and so on.
Horizontal mouse headerbar drag to scroll the view was a lifesaver. Definitely a good choice adding this. Along with scrolling the view on DnD near the screen edge. Going through the overview, or always through the keyboard, would be very annoying.
yuxqiu just improved the default GPU detection logic in Smithay, so niri-git now works out of the box on Asahi and Pinephone devices, without having to manually configure render-drm-device!
-
yuxqiu just improved the default GPU detection logic in Smithay, so niri-git now works out of the box on Asahi and Pinephone devices, without having to manually configure render-drm-device!
i added the pointer warping thing from blender to when you drag the view around in niri with the mouse
hf with this new way to pass time during boring meetings
(on a more serious note this helps when you need to scroll further than the edge of your monitor allows)
also unrelated: merged optional config includes earlier today
-
i added the pointer warping thing from blender to when you drag the view around in niri with the mouse
hf with this new way to pass time during boring meetings
(on a more serious note this helps when you need to scroll further than the edge of your monitor allows)
also unrelated: merged optional config includes earlier today
on niri-git, the nautilus rename popup now works properly with IMEs running
(and generally popups with text fields should work now)
-
on niri-git, the nautilus rename popup now works properly with IMEs running
(and generally popups with text fields should work now)
Experimenting with a restructure of the niri rendering code to uncurse it somewhat by getting rid of all complex impl Iterator chains and lifetimes, which also lets me remove some intermediate small Vecs. In essence, going from pull to push iteration.
I'm surprised that the result is consistently 2-3x faster than before. Wonder if it's the Vecs, or if inverting (massive) codegen'd iterators into a normal call stack passing a closure arg, providing the main benefit
-
Experimenting with a restructure of the niri rendering code to uncurse it somewhat by getting rid of all complex impl Iterator chains and lifetimes, which also lets me remove some intermediate small Vecs. In essence, going from pull to push iteration.
I'm surprised that the result is consistently 2-3x faster than before. Wonder if it's the Vecs, or if inverting (massive) codegen'd iterators into a normal call stack passing a closure arg, providing the main benefit
Finished the push-based rendering refactor, made a write-up here for the curious: https://github.com/YaLTeR/niri/pull/3113
It even ended up with a negative delta (+762 -780) which is always a W.
Btw I ran the comparison on my Eee PC and there the difference is even more extreme, like 8x faster rendering list construction (which is once again only a part of the total rendering time, and notably doesn't include actual rendering, but still nice).
-
Finished the push-based rendering refactor, made a write-up here for the curious: https://github.com/YaLTeR/niri/pull/3113
It even ended up with a negative delta (+762 -780) which is always a W.
Btw I ran the comparison on my Eee PC and there the difference is even more extreme, like 8x faster rendering list construction (which is once again only a part of the total rendering time, and notably doesn't include actual rendering, but still nice).
biblically accurate window management
-
biblically accurate window management
i'm reviving the PR integrating Tracy GPU profiling into Smithay. Here are two test captures from niri: one for normal + screencast rendering, one for iGPU + dGPU monitor rendering
-
i'm reviving the PR integrating Tracy GPU profiling into Smithay. Here are two test captures from niri: one for normal + screencast rendering, one for iGPU + dGPU monitor rendering
Looking for ideas on how to go about translating niri (the binary, and the wiki). If you have experience doing this with other FOSS projects, please share:
-
Looking for ideas on how to go about translating niri (the binary, and the wiki). If you have experience doing this with other FOSS projects, please share:
Is there any good way of moving a process into a systemd StartTransientScope together with its children?
In niri we put spawned processes into scopes, so oomd and other stuff can work properly. Usually you do it by putting yourself into a scope, then exec-ing the target program. But that's a 7 ms toll on startup time, so in niri we spawn the program right away, and then put it into a scope. However, if the program forks fast enough, that child doesn't go into the scope..
-
Is there any good way of moving a process into a systemd StartTransientScope together with its children?
In niri we put spawned processes into scopes, so oomd and other stuff can work properly. Usually you do it by putting yourself into a scope, then exec-ing the target program. But that's a 7 ms toll on startup time, so in niri we spawn the program right away, and then put it into a scope. However, if the program forks fast enough, that child doesn't go into the scope..
Turns out GNOME Shell has the same problem: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565
I also wrote it down in a more detailed form on the niri issues for future reference: https://github.com/YaLTeR/niri/issues/3201
-
Turns out GNOME Shell has the same problem: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6565
I also wrote it down in a more detailed form on the niri issues for future reference: https://github.com/YaLTeR/niri/issues/3201
niri can now include the mouse pointer on window screenshots, a feature that had several more edge cases than I thought before starting to work on it (and it's likely not the ones you think, those ones were easy)
