Usability issues with Niri

I tried out Niri recently. It’s great! It’s really polished software. The developer seems awesome, the docs are straightforward and fairly comprehensive, the compositor is beautiful and works well.

Niri is a Wayland compositor. It’s a descendent of what have been known as tiling window managers – a way to manipulate application windows that contrasts with the usual “stacking” drag-and-drop and drag-and-resize approach of normal software.

The idea is, rather than make the user resize windows and such on their own as they like it, do it for them. Keep windows as large as possible, but make space when new ones spawn in so there’s no overlap. If there are too many windows in a view, a user can send some to another workspace, but everything in a workspace should be visible.

This makes things much more naturally amendable to keyboard navigation, too – if your windows are in predictable places you can predictably move between them with predictable commands.

Niri takes a bit of a twist on that. It’s still tiling – windows still spawn in to take up as much space as possible (vertically), and there’s still an effort made to not have any windows overlap, unless you explicitly tell them to. But rather than making space for new windows by shrinking old ones – new space is made by way of spawning them into an infinite horizontal sprawl, with older windows pushed offscreen to the left/right. A user can then scroll between these windows with a hotkey or by a swipe on their trackpad. There’s a couple of these scrolling window managers out there.

In Niri’s implementation, there’s also workspaces – scrolling horizontally sweeps across open applications in the same workspace, while scrolling vertically switches between workspaces. And there’s good mouse support. Everything that can be done with the mouse can also be done with keyboard commands, but the mouse and click-and-drag provides some useful discoverability.

It’s a really neat design. And as previously mentioned, it’s good software.

I did not, however, find it to be workable for me, and after a week I am switching back to KDE. There are several problems I have with Niri. They’re persistent problems to the core of the design of the compositor. They’re probably not fixable, not without some extensive thought put into computer touching generally, and I really don’t have many thoughts towards fixing them myself. I’m listing them here though, and I’m writing this post, because I think they’re kind of interesting.

i don’t know where anything is

This was probably my biggest problem with Niri and my main motivation for switching back to KDE. I welcome suggestions on how to fix it.

Niri functions by pushing windows you’re not using offscreen. You can only really fit two, maybe three usable windows at once, like any tiling system. But other tiling systems make you move windows elsewhere to gain space. Niri does it for you.

And out of sight, out of mind. I instantly forget where any window is the second it vanishes from my view. This hasn’t been the case when I’ve used other more traditional tiling systems: maybe there’s something to the performance of moving a window to a workspace that makes it stick in my head? Or maybe there’s something about that you see all the windows of a traditional workspace at once when you switch between them, whether tiling or stacked (via overlap)? I don’t quite know.

All I know is, this doesn’t work for me.

Now, to its credit (because Niri deserves such credit), Niri has a couple of things going for it to fight this off. First, there’s the workspace view. A four-finger swipe-up gives you a birds-eye view of your computer, showing three workspaces at a time and the windows immediately off the left/right-hand side per workspace. You can swipe between workspaces and windows here too, and even change the focus and manipulate the windows (although you can’t move around the workspaces, but this is a tracked issue). Second, there’s a third-party fuzzel script (fuzzel is the default launcher) to select and switch to open windows. But this one isn’t great: it doesn’t ship with Niri or even fuzzel by default and it doesn’t work for applications with inaccurate titles (which I’ve now noticed quite distinctly). And, it doesn’t really show me where windows are… but, it works.

However. I’m very well aware the above exist, but I find myself not using them. I think my mental model here is “oh this window’s close by,” and then I swipe around and can’t find it, and then I don’t find it and finally pull up the overview. Same goes for the switcher.

Not sure what to do about that.

i can’t effectively switch between things

I cannot effectively switch between windows in Niri. I end up going, swipe swipe swipe swipe left swipe left swipe up swipe left swipe left swipe left swipe right. This hurts my hands and is generally unpleasant. It’s further aggrivated by the previous point… I don’t know where things are, which makes switching to it harder, and when I don’t know where anything is, there tend to be more spawned windows to swipe through. But even when I do know where things are it’s a problem.

I really want some kind of Alt+Tab. But not ordinary Alt+Tab, because of course that won’t work. Just… something. A popup, maybe. Or image previews in the aformentioned window switcher script, to make me a little more effective at recognizing the window I want to switch to. The usual behavior of Alt+Tab solves this stuff pretty handily: ordered by recency, pops up previews when pressed multiple times, etc. I am sympathetic to arguments against Alt+Tab, though. I am! I broadly agree with posts that characterizing that method of interaction as needing to react to your computer rather than have it react to you. Alt+Tab is very stateful. You just don’t keep your application history in your head enough for it to be terribly effective, beyond the top of the stack. And so, I understand why there is not really any sort of Alt+Tab for Niri, or for tiling systems in general.

But what’s here now is not enough.

(I also welcome suggestions from the audience for how to fix this one.)

it’s all too modular for me

The first issue I ran back into (and the last one I’m mentioning here since it’s mostly irrelevant) is one that’s been a problem forever, across both X11 and Wayland, and will continue to be a problem. Like the rest of what I’ve been outlining here – it’s an opinionated problem. It is notably not a problem to many people, instead being a desirable property… but, as for me, I don’t like it.

Niri’s a Wayland compositor. It’s only a Wayland compositor. It’s not a desktop environment. It doesn’t work with desktop environments. Or rather, it’s more accurate to say desktop environments don’t work with it… Wayland (and previously X11) are designed in a modular fashion. A window manager (X11) / compositor (Wayland) does one thing: it manages windows.¹ However, existing desktop environments like KDE and GNOME are designed in a monolithic fashion, integrating heavily with their compositor and pulling pieces in for ease of development, historical reasons, and because you genuinely can provide better UX out of such a monolithic system.²

This means you can’t just swap out the compositor and call it a day though. Which sucks! I want to use KDE’s floating bar! I want to use KDE’s settings panel, and have it manage my themes and such, and use its program picker and display configuration tool and its general functionality! I want to use KDE’s really good screenshot tool, most of all!

But I can’t, and I’m sad, and I have to piece together a dozen tools for a worse experience.

This is maybe stoked by there being quite a bit of ecosystem churn on Wayland. Now, I like Wayland – I think it’s a better model than X11 and I’m glad people have generally stopped having silly flamewars about these things on the internet. But there is churn.³ Both in the way of protocols and their uptake among compositors, and also in the way of software itself – some of the software around Wayland is, not very good? The external display controls kinda suck. And other aspects have too much good software. swaybg and swww? mako and dunst and such? yambar and waybar and swaybar and so on and so forth? What’s good, what’s bad, what’s there to check out and use?⁴

But really I’d be happiest if I could just use KDE.

why’d i try out niri in the first place?

Well, there’s some things that aren’t great about KDE.

Currently gesture support is a second-class citizen. It just, sucks. Response curves and animation curves aren’t configurable. Gestures aren’t rebindable, nor separate from the “natural scrolling” setting of the trackpad. There’s not been a whole lot of upstream interest about this, which I think is a shame, because the KDE gesture experience out-of-the-box is strictly worse than GNOME’s, which (while still not being configurable) have had a lot more polish put atop them.

Window management is also not perfect. There are a fixed number of workspaces by default. If you want more, you have to create more. I’m running a Dynamic Workspaces plugin which pretty much entirely fixes this, though. But it’s also… KDE wasn’t designed with dynamic workspaces in mind, so it doesn’t have the best way to present them, mostly copying from MacOS’s UI.

Niri offered something better. And on these points, it succeeds. Gestures are configurable and rebindable⁵ and feel nice out of the box. And, yeah, not needing to really manage application sizes is nice. KDE has actually been regressing on their tiling feature support… just recently, they broke a part of my workflow, being that Ctrl+dir twice in the same direction used to bounce a window back to where it once was. This default was removed, tragically, and unusually for KDE, without any configuration exposed for bringing it back?⁶

a few other things

A couple of last notes on Niri.

conclusion

So anyway, I’m gonna switch back to KDE. I might try out the Karousel KWin script. I’ve heard it’s similar to GNOME’s PaperWM plugin. I think a good number of my issues might be solved by keeping the core desktop environment of KDE, but we shall see. I’ll post an update on how it goes.

In the mean time, cheers, and to the Niri developer, if you read this – keep on keeping on! Maybe this post will inspire some revelation about the interaction model, and if so I’d love to hear it, but for now it certainly seems like many not-me people use and enjoy Niri, which is awesome.