Niri 26.04: Scrollable-tiling Wayland compositor(github.com) |
Niri 26.04: Scrollable-tiling Wayland compositor(github.com) |
The challenge with macOS window managers seems to be handling movement of windows between spaces, particularly when the display configuration changes (e.g. when docking and undocking a laptop, or opening and closing the lid). I've tried Yabai, AeroSpace, OmniWM, Hammerspoon w/ PaperWM.spoon, and Rift. None of them have delivered the level of polish Niri achieves.
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.
I started with Hyprland when it didn't have scrolling built-in and all of the scrolling plugins were either really buggy or missing important features.
Ended up very quickly switching to niri and never looked back because I found it to be much more stable in general, plus niri handles multiple monitors in IMO the perfect way. niri is much different than Hyprland. It's not only about scrolling windows. It's how everything is put together and works together.
Also, my dotfiles come with a custom Walker menu to find and search through niri key binds, selecting the key bind will run the action too.
With that said, if you're using my dotfiles and want to use this tool, it would be as simple as adding "nirimod-git" to the `PACKAGES_AUR_GUI_EXTRAS` variable in your config file.
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)
It works a charm.
I think I'm completely done after like 6 hours which is insanely fast, and it really is everything I ever wanted. It is cohesive, easy to style, has good defaults, includes essential programs like polkit agent and notification daemon / osd, has a ton of plugins.
I should have tried it so much sooner.
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).
There are a few discussions around this, so I'm hopeful to see it implemented at some point:
- https://github.com/niri-wm/niri/discussions/1318
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
Also I've been missing scratch deeply.
I'm sure it's solvable with some diligence and config changes, but I haven't invested the time yet.
Other things that help include a fuzzel-based open window searcher and, to be honest, restrained use of Niri's flagship scrolling feature. Most of my workspaces most of the time are the same size as my screen, with the scroll used very sparingly for usually temporary overflow.
I guess it also helps that I never used the i3 scratchpad so I don't miss it.
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.
For me, the spatial mapping of windows comes naturally, though. For MacOS, I have 9 spaces. This can be as many or as little as you want, but for me, I have keybindings to switch between them, starting with ctrl + shift and then I map it to:
u i o
j k l
m , .
With that being said, things I'm frequently using (browser, terminal, mail, music, discord, etc) have their own global keys set to launch or switch to them and that is actually what I use most. I think if you can think about how you'd like to organize your system, just practicing that will help you reason about it that way.
I've been trying Niri on my thinkpad and I really like it, though I think I agree that it can be trickier to spatially map where things are in it. Its spaces are vertical and then you are scrolling the horizontal plane. They aren't always the same dimensions because it depends on how many windows are open. Getting back to say, the top right space, requires more work, at least out of the box. But on a smallish laptop screen I think it is well thought out way to make it easier to swap between different views.
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...)
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.
Niri offers a wonderful workflow; it really is an excellent piece of software.
> Each monitor contains an independent set of workspaces arranged vertically. [...] You can move a workspace to a different monitor [...]
> When you disconnect a monitor, its workspaces will automatically move to a different monitor. But, they will also "remember" their original monitor, so when you reconnect it, the workspaces will automatically move back to it.
If he sticks with the project until he grows out of the impulsive phase, hyprland will be in a much better place.
I never understood the point of per-app workspaces. I hate having, for example, a single Firefox instance open with everything mixed in, from work to leisure.
Being able to have one window of Firefox per project workspace, with only tabs relevant to that project - this alone is a better than the myriad of ways Firefox themselves have tried to solve it within the app.
With niri I just open another window and it's where I need it and all other windows are still to the left and right so I just "scroll" there. Now I'd say my workflow is messier now, but I think that's actually a good thing. Tiling window managers require (but also make it reasonably easy) to be organised. With niri I don't have to be organised. Sometimes it you can't find a window immediately, but you can just use overview (and I also have a window search rofi). Initially I still had some named workspaces similar to my sway tags, mainly because I found I was still switching to them out of habit. Nowadays I don't use them any longer.
Where tiling WMs shine is when actually tiling windows. For me it's the holy trinity of Browser, editor and terminal all visible at once, and navigatable spatially via super+hjkl or super+up/down/left/right. So I have one workspace per project which makes a lot more sense to me as an actual workflow for tiling WMs.
Niri just improves on this substantially by allowing new windows to open to the right, instead of messing with the existing layout in the current workspace. For example, if I need to open a pdf or something. I get to keep the holy trinity, but swap over to the new window easily.
If one uses a manual tiling window manager like i3 or sway and a large monitor one can divide the screen into separate work areas that each host multiple applications based on their role in one's workflow and use less workspaces.
Scrolling makes a similar but different workflow practical on small screens where flexibility matters.
Most workspaces are a fullscreen browser or some other app to the left, fullscreen editor in the center, tmux on the right.
I still use tiling within a monitor to view email side-by-side with browser, or a document or two side-by-side with code. Rarely feel the need to put 3+ apps in a complicated layout on one screen since I’m usually not gonna be cross-referencing at them all at once.
If I had one monitor I wouldn’t want to be taking up half of it showing the browser all the time when I could instead use that real estate for more vim splits.
I generally use one workspace per task with some workspaces dedicated to specific apps (eg my browser workspace). Every app is full screen, always. I tend to use niri’s scrolling mainly for related work on one task, for example, I have my editor working on a project, scroll left and I have kilo code open on that project, and scroll right I have terminals or other related things.
So I mainly use a sway-like workflow except things tightly coupled to a specific task as on the same workspace and I scroll left or right to get to them. Everything is either full screen or sometimes 3/4 width (and full height). Occasionally I have two terminals vertically split on one column.
I've avoided needing them because of 2 niri features:
- You can quickly tap alt+tab to focus the last previously focused window (assignable to a custom bind if you want)
- niri's CLI is very easy to work with so you can build a general purpose "launch or focus" shell script in a few lines of code
If you have something like Discord or any app you want to only be opened once, you can "launch or focus" it and now it's running somewhere. Somewhere as in, you can control which workspace it's on at your discretion.
Then if you launch it again from anywhere, you'll jump right to it instead of launching a 2nd instance and you can tap alt+tab to go back to exactly where you were before.
A nice effect is after it's been launched once it never interferes with your existing windows since nothing is getting opened again.
I'm after the end result of "let me access this program quickly no matter where I am", it doesn't need to literally follow me around every workspace to do that.
The launch or focus model can be applied to GUI apps and also TUIs.
=== SPATIAL MEMORY ===
niri's overview gives you a holistic view of everything. Status bars can also show you which workspaces are in use (and even open apps if you want that).
In addition to that, certain launchers like Walker have shortcuts to let you switch windows. This means you're only ever 1 global hotkey away from seeing a list of every window that's open and being able to fuzzy find switch to it in a second. I use this all the time. If you're not using Walker you can build this in a few lines of code since niri's CLI gives you a list of open windows.
My dotfiles have both things set up https://github.com/nickjj/dotfiles.
I will try the Alt+Tab alternative to scratchpads.
However the spatial memory concern I talked about isn't exactly of losing windows and trying to find them.
The script you mentioned seems useful to jump faster between windows you are not sure where they are. But what I tried to express is that when I'm in a workspace in i3, I have "perfect vision" of whats inside the workspace, niri I sometimes I have "tiny lapses" of having myself asking "where's the terminal, is it on the left or right of my browser?" this is not "losing the window" is just tiny frictions of having to think where a window is.
I don't know if that was a first impression that could just be solved with better attention and organization(I confess that my first try with niri was not on my work PC, but my media one that is attached to television, so I was not using niri exactly on the same mood I use i3wm).
Soon I might give niri another test drive, thanks again!
What does this mean?
What else than a video would be suitable for demonstrating this software?
niri's alt+tab also has a filter where if you hold alt and then press "w", it will only show you things on your active workspace. There's a little label that pops up showing this. You can also press "o" to filter it for only 1 monitor (output) too.
The above might help with those lapses.
In my case I haven't experienced this because I'm usually after the end game destination which is focusing the app so fuzzy finding it is the quickest path to that. If it's 8 windows to the right or 3 to the left is all the same to me.
With that said, I do sometimes have sessions where I have 3-4 things open side by side and I quickly cycle between them by going left and right. In those cases I don't have memory lapses because there's only a few windows open and I'm doing something specific. When this task is done I usually close those windows or no longer need to remember their relative position to windows in view.
I bet you could create a cool looking horizontal mini map to show a strip of things open on a workspace, this way you don't need to open up other things (overview, alt-tab, window finder, etc.) to see where things are.
I tile within one monitor when I legitimately want to see things side by side, but I certainly don’t want firefox permanently taking up screen space when I really only need to occasionally look at it. Usually it’s on a separate monitor in the same workspace, or in a dedicated workspace.
Maybe there’s some way I could manipulate stacks and zooms to achieve that within one workspace, but I’ve always found it easier to just have firefox on a separate workspace I can easily quickly swap to and from when needed.
i.e. if i have virtual desktops 1-2-3 on my 3 screens in order, I can switch out 2 for 4, but 1 and 3 stay put, so 1-4-3. if I want 1 to be in the middle now, I will switch 1 and 4, then I have 4-1-3. Now I can get 5 onto the left and have 5-1-3.
And it does not matter if I have a single big window, or whatever tling wm layout.
The point is that everyone can work however they want. When I use a tiling WM, half my screens/virtual desktops are fullscreen and half are tiled. sometimes 50:50, sometimes in other ways.