I may end up making a video about this, but I honestly don’t know if I have enough content for that, so it goes here first. A few days back, as of writing this, I decided to finally try Niri, the newest Wayland compositor. People have been asking for a while, and I decided it was finally time to give it a go.

Install and Pre Setup

The installation wasn’t difficult at all. Niri is in the openSUSE repos and I already have waybar installed. Before I hopped into the session, I pulled down the default config to make some changes. The config file is in a format called KDL. I had never heard of this, but it is fairly similar to what Hyprland uses, only with a different comment situation. I’m sure there are other differences, but it was similar enough that I didn’t feel out of place.

My first task was to set up my monitors. This was done with three different sections, one for each monitor. Like with Hyprland, you need the resolution and the monitor’s position. I just grabbed these numbers from my Hyprland config file. Niri offers several configuration options for your monitors, allowing for most monitor types and configuration. Exactly what you’d expect from a Wayland Compositor.

Next, I made some initial changes to key bindings. I changed from Alacritty to Kitty and I added a binding for Rofi, which ended up not working, more on that later. Once I got this done, I logged out of Hyprland and into Niri for the first time.

First Impressions

This is pretty cool, were the exact words out of my mouth. Niri is a scrolling window manager. Meaning that each workspace goes on forever, with each client being added to the stack, shoving all previously opened windows to the side. This would be awesome on a laptop.

For me, on the desktop, my biggest worry was how Niri would handle multiple monitors. The answer to that was not bad at all. Each monitor behaves as a workspace, and each workspace is infinite. You also get actual workspaces on each monitor, and each of those is infinite. That’s effing awesome. Y’all know how I love me some workspaces.

I did encounter my first issue here upon boot: I couldn’t get rofi to launch with my key binding. In the config file, I had something that looked like this:

Super+D { spawn "rofi -show drun"; }

This did not work and I had no clue why. It took me for ages to remember that DWM does this same thing in C, where any commands that are a part of a binding must be separated out, or it won’t work.

Super+D { spawn "rofi" "-show" "drun"; }

That worked, and I had rofi.

Playing Around

Before I got too serious about configuration, I wanted to see what this thing could do. So I set up bindings for Vivaldi and a few basic apps, and started to just use Niri as if it were my home window manager. Vivaldi launched fine, and I moved it around a bit. I looked up some of the bindings I’d need to move things around in the stack and from monitor to monitor. Niri’s devs have done a good job of having bindings in place for people who have more than one monitor. They’ve also anticipated most movements you’ll need. I also learned how to make clients full size and bigger and then smaller.

It was a very interesting workflow. I feel like if I were to use this, I’d use the keyboard even more than I already do to move things around. I also have a feeling I’d actually use fewer actual workspaces than I normally do. With the infinite scrolling capabilities, there’s no reason not to put more clients on each workspace. It makes it, so I don’t have to actually have ToDoist on one workspace, Obsidian on another. Place those on the same space and just scroll between them. No need for 20 individual workspaces anymore.

Scroll. That’s an interesting thing to type, given that I never actually used my scroll wheel to scroll the windows. I don’t even know if it is possible, I’m assuming that it is. The key bindings to move around were so good, I didn’t even think about using the mouse.

Deal Breaking Problems

It was once I started to want more apps open that I started to discover a big, big problem. Niri out of the box doesn’t use Xwayland. Now, most things I use, that doesn’t matter. But I have a few electron Flatpaks that still requires an X11 server to be running. Xwayland is the service that every desktop environment and compositor uses to ensure that X11 apps can still run on Wayland. Things like Steam, OBS, Discord, ToDoist, Cohesion, all the apps I actually use for my job and online social life, need Xwayland, and Niri doesn’t support it.

So when I went to open ToDoist, nothing happened. And I was flummoxed. “What is going on?” I asked. So, I tried to run the app from the terminal, the first thing you should do if an app doesn’t launch, and it spit out X11 errors.

That was when I did some Googling and discovered that Niri doesn’t support Xwayland. Instead, they’ve chosen (for some silly reason) to be different from every other DE and WM out there and use something called xwayland-satellite. I don’t know the technical details of how this works, or why they chose this, but I could not make it work. I spent hours working on it, I got some help from friends on the Discord, and nothing. I was unable to get any Flatpak that requires X11 to open. It just would not work.

This is a dealbreaker. There are apps I have to have. I can use some of them in the browser, but that’s not the way my workflow works. And after trying for hours to make it work, I just gave up and went back to Hyprland.

I’m assuming that there is something openSUSE-related going on here. They do something odd with Flatpaks that installs things in User Space, and that always requires some special permissions. I don’t know if that is what’s causing this, or what. Whatever it is, it’s disappointing because Niri showed a lot of promise.

Infinite Workspaces

I love this idea, way more than I thought I would. I didn’t think it would work well on a multi-monitor system. It does. I didn’t think that the keyboard movement and motion would work as well as it does.

The fact that bone-headed developers had to be “different” and not use xwayland for “reasons” just makes me sad. This is a core functionality that people have worked hard for, and they tossed that compatibility layer out the window because they wanted to be different. Okay, maybe they have technical reasons, I don’t know. I also don’t give a rip. This is silly, and actually makes their otherwise awesome window manager unusable. Even if I had managed to get the workaround with xwayland-satellite working (most other people have), this would still be a dumb situation to be in. Why add extra work onto things for your users when a standard already exists? I know that they’re going to build in the functionality in the next version, but they wouldn’t need to do that if they just used Xwayland to begin with.

You can tell I’m a little salty about this whole thing. That’s because I really like what I saw from Niri. It has serious potential. And I love that there is something out there that can compete with Hyprland. It gives me hope that other compositors can flourish. But Niri might die if the dev team decides to make irrational decisions just to be “different”. That same attitude made Hyprland unusable for almost 48 versions. Don’t be like Hyprland, Niri. Or do. Use Xwayland, it works great.