I have a huge amount of gratitude towards the author of niri.
My dotfiles have always included an install script for setting everything up around command line tools, theme switching and more but it fully supports niri now too on Arch based distros https://github.com/nickjj/dotfiles in case anyone is shopping around for a new desktop environment and wants to get going quickly. I run it on both my main desktop and a travel laptop.
https://github.com/BarutSRB/OmniWM
I posted about it a bit ago when I just started using it, and it's been really great. Highly recommended.
But I’m giving it a real shot, and the nice thing about it being a Gnome extension is that the rest of the Gnome DE is right there without a ton of config.
Would love to hear the perspective of anyone who switched from a similar workflow to Niri. How does the mental model shift?
The dank case for scrolling window managers - https://news.ycombinator.com/item?id=46820468 - Jan 2026 (61 comments)
Niri 25.11 released with alt-tab and other improvements - https://news.ycombinator.com/item?id=46097051 - Nov 2025 (1 comment)
Niri – A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=45461500 - Oct 2025 (229 comments)
The Future Is Niri - https://news.ycombinator.com/item?id=43342178 - March 2025 (216 comments)
Niri: A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=37367687 - Sept 2023 (37 comments)
Totally not mass psychosis guys pump the SPY
My only remaining pain point is that its X compatibility layer, xwayland-satellite, does not yet support drag and drop between X and Wayland programs.[2]
[1]: https://davidyat.es/2026/01/28/niri/
[2]: https://github.com/Supreeeme/xwayland-satellite/issues/133
Being a i3wm(now sway) user, I tried Niri but found the following points a little bit uncanny:
- (Cropping) Sometimes when I scroll by shifting focus, a little bit like 10% of the window I pushed to the left keeps appearing. I tried to configure Niri in such a way that never a tiny fraction of a window be cropped but couldn't manage. Not sure I missed some config though.
- (Scratchpads) No scratchpads. There's workaround that I saw using extension scripts, but felt cumbersome to use(not the script itself, I just wished it was native feature on Niri). I use scratchpads a lot for "global" apps like email, discord, obsidian so I can open them on any workspace I am at, then make them disappear completely after.
- (Spatial Memory) By being used to i3wm I am comfortable pushing different applications so they can fit on a single screen. In i3wm i have "perfect vision" of a workspace. Niri style keeps me "forgetting" what's to the left and right. I know I can zoom out, but feels like friction upon my short term memory.
I would love to receive any suggestion so I overcome these points that I stumbled upon. Soon I might be trying Niri again on a more work environment(my first try was on a PC connected to TV, so more media focused usage).
I encourage everyone using the ubuntu/windows paradigm to check this out instead. Windows users see me working and their jaws drop, because it's so fast and smooth.
If anyone's curious I use ALT+: e for file manager (thunar), w for chrome, a for whatsapp, x for terminal, c for claude web, y for youtube, n for a notepad-style program, d for launcher (fuzzel), t for sublime, z for emacs, v for clipboard history, f for full screen, q to kill active and f1 for a emacs capture-dialog. g sends a window to a ws on my main monitor, and alt+shift+g sends it to secondary monitor.
One thing I learned in the process was that the custom wayland desktop world has the concept of a "desktop shell," which provides most or all of the additional components you might want on top of your compositor, rather than having to separately install a top bar, manage suspend/hibernate, figure out notifications, etc. You can of course still do all of that, but you can also just install niri and something like the "dank material shell"[0] and be off to the races. I first discovered this via awesome-niri[1].
The combination of niri and the shell means that the extent of my custom NixOS configuration for the two is entirely limited to keybindings and some custom window rules for zoom.
> Every monitor has its own separate window strip. Windows can never "overflow" onto an adjacent monitor
I'm someone who was very content with the constraint of a laptop (one single screen, generally running one maximized window per workspace and switching with F-keys), but has never really become comfortable with multi-monitors. Can anyone explain why window managers always default to treating individual monitors as completely separate entities rather than one larger screen that works together? Like I would have thought the default here would be to have two monitors operate on the same horizontally-scrolling set of windows. Either tied together, or as independent viewports. But everybody always seems to reach towards treating each monitor as having disjoint windows. Which I guess I can get used to, it just seems odd?
This, for X, but not under Gnome or KDE? Even better, perhaps as just a script or something under Openbox?
(might be time to get into the vibecoding...)
I think I would’ve adjusted best if I could somehow just watch someone do their daily work on Niri, to learn how to use it right. Curious if people who like Niri came from tiling WMs or standard DEs.
Before that I was on sway for 6 years, before that on i3, before that on KDE, Gnome, ...
I'll never look back.
Niri is the best window manager I ever used, it just instantly clicked with me.