The Future Is Niri(ersei.net) |
The Future Is Niri(ersei.net) |
Viture comes to mind.
In the old days, we could choose when to upgrade (often at a significant financial cost). Now, things change out from under us without any notice whatsoever, or maybe with an annoying tutorial that pops up at the most inconvenient time possible.
> If you don't find yourself constantly swapping between fullscreen and non-fullscreen views and running out of workspaces, you don't have very many windows open. Don't even get me started on tabbed/stacked layouts with nested containers, the least ergonomic Band-Aid™ for the space issue I've ever seen.
On the contrary: I think this author really ought to get started on tabbed/stacking layouts! Constantly swapping between fullscreen and non-fullscreen views, like running out of workspaces, definitely sounds like an antipattern to me. I don't believe that the number of windows is the problem here.
If I'm deep into something, I might have 10 or more windows open, all on one workspace, on a 13" 1080p laptop panel. Of course, not all of the windows are visible at once. A common pattern for me is to have most of my screen taken up by a container split "horizontally" (meaning into a left side and a right side), where each side can be a tabbed container containing several windows. For example, I often have Emacs on the left, and several tabbed terminals (including man pages) on the right. Maybe some of those terminal tabs on the right are split "vertically" into a top and a bottom terminal (e.g. for a shell prompt on top and man page on bottom). Outside of this big left-right split container, which fills almost the whole screen when it's visible, I'll usually have some browser windows open. If it's just one browser window, I'll put it and the big-left-right-split (BLRS) in a stacking container. This way, you can think of the browser as being "above" the BLRS, and you can get there and back by moving the focus up and down again. It's like each stacked item (the browser and the BLRS) gets its own workspace, in that they each take up nearly the full screen when visible, but actually they're both on the same workspace, and the only cost is the loss of one title-bar's height of screen space. Then, if I want more browser windows, I can split the existing one into its own tabbed container. (I use both WM tabs and browser tabs, just like I used to use multiple browser windows on one workspace with Gnome.)
Basically, as my number of windows grows, things become (slightly!) more nested, rather than being ejected into surrounding workspaces. The trick to making this ergonomic is to choose what to stack vs tab so as to allow you to flip back and forth between (at least) any two windows with just a couple keys. (I also have two keybindings to split a container and immediately make it stacking or tabbed, and also two keybindings to focus parent-wards/child-wards. Then, you can easily jump from a window in the middle of a tabbed container on the right of the screen to the window on the left half of the screen---you just focus parent-wards then left (two keys). To get back, just focus right (one key).)
I should also add that I haven't really seen any problems with apps behaving badly when being resized, including Firefox. Maybe that's because my workflow mostly looks and feels like "slots" of a few different sizes (roughly full screen, half screen, quarter screen), and adding new windows to, or moving windows between, these slots is never going to change the size of the slots or the windows displayed in them. In fact, with traditional floating window managers, when has resizing a Firefox window ever caused me to lose my place in the page? Only when I make it super unusably narrow, or short, or both, and then expand it again. This is what would happen if you open a bunch of windows all in horizontal and/or vertical splits, with no stacking or tabbed containers! But why would you do that?
This is exactly what TFA mentions: you van remove choices via a simpler model that does not really sacrifice anything.
Tabs are oriented along a horizontal axis; as with hsplits, you move through them by moving the focus left and right. Stacks are oriented along a vertical axis; as with vsplits, you move through them by moving the focus up and down. The reason you want the ability to choose between the two options is (to continue parent's quote of GP) "to allow you to flip back and forth between [relevant pairs of] windows with just a couple keys". To reuse (and better explain) the example from GP:
[ _ _ Tabbed Browsers _ _ ]
-------------------------------------
| emacs | Tabbed Terms |
| | |
| | |
| | |
| | |
So, the choice between stacking and tabbed matters. I'm not saying you can't have this choice in a scrolling tiling window manager. (Does Niri have stacking and tabbed containers? I hope so.) I'm also not saying that you or anyone else has to want to make that choice (it's okay to prefer a "simpler model" where you scroll around to get to all of your windows). What I am saying is that the author of TFA thinks that with traditional tiling window managers like sway, you can't have "very many windows open" without "constantly swapping between fullscreen and non-fullscreen views and running out of workspaces", and this is simply not true. (Perhaps worse, in the next sentence, they dismiss the solution out of hand by saying "don't get me started" on nested tabbed/stacking containers, because they're "the least ergonomic Band-Aid™ for the space issue I've ever seen", but it seems to me that declining to give a full treatment to that subject may actually be why the author's never seen it done ergonomically. But now I'm speculating.)
------
BTW, since anyone still reading is probably a completist: at the top, I said that directionality was "one of the" important differences between tabbed and stacking containers. The other one is how much space their title-bar areas take up vs. how many children they have. Stacking containers are O(n) in the number of children; tabbed containers are O(1). Interestingly, combining this with the directionality property yields an interesting result: in sway, there is a sort of asymmetry between the horizontal and vertical dimensions.
The author is ~21 and seems worried they're old ? I had a good giggle about that.. And then it dawned upon me how old I actually am.
[olvwm]: https://en.wikipedia.org/wiki/Olvwm [distro]: https://ces.mataroa.blog/blog/distro_hoppingmd [xview]: https://github.com/olvwm/xview
This being said, time for my daily nitpicking: 7÷0.35=20, not ~21. Although I agree that 20 ≈ 21.
/cries in half century
Reminds me of that explanation for why the years seem to move much faster when you’re older. When you’re 10, five years is half your life. When you’re 50, it’s only 10%.
I’ve been using Sway for the last five years and i3 for a few years previously. They work fairly well for me, I certainly didn’t have any of the problems the OP mentioned.
My all time favourite window manager, though, and one I wish would be revived (perhaps as a wayland WM now. How I wish I had the free time to take this on…) is GOOMWWM which I used for a decade prior to i3 (and Musca before that).
I use labwc currently which has the ideal workspace behaviour (one workspace shared).
Some basic things like notifications, keyboard controls for volume/brightness, sound etc don't work the best in i3wm by default and requires some fiddling on each machine to get it to work properly.
I love the out of the box behavior of my Mint installation and don't want to switch completely to something like i3wm. I could get even a watered down version tiling and stacking like i3 with keyboard shortcuts, I would be very happy. There is gTile but it doesn't quite work the same way.
https://github.com/ellysaurus/KWin-TilingGuide/
https://github.com/paperwm/PaperWM
https://github.com/peterfajdiga/karousel
there might be more
If I didn't need a Web browser and a PDF reader I wouldn't be running X at all... I wish there was a usable alternative for the browser and PDF reader that didn't require X...
Cosmic Desktop (creators of pop-shell) is further innovating in this area as well.
While Niri might be easier to install on Arch I would still suggest giving PaperWM a try for a week. I ended up missing it waaay too much after disabling it for a few days on a whim and now I can't imagine using a computer without a scrolling WM given the choice.
Just uhh... Keep a keybindings cheatsheet nearby, like the one in the PaperWM GitHub repo.
(watch the bottom-right readout on the video)
Or am I misunderstanding "changed somehow to keep the selection happening after you released the mouse".
(I understand that people don't like UI changes that break their muscle memory of course.)
If there's something that the Rust community does well it is capturing enthousiasm to get stuff done.
> Display scaling (integer or fractional) will make X11 apps look blurry; this needs to be supported in xwayland-satellite.
The author linked their config file from the article, and it includes this:
// Animation settings.
animations {
// Uncomment to turn off all animations.
// off
Last time I tried, a few weeks ago, it wasn't better.
The Windows scene is definitely the place where the most interesting workflow advances in "traditional" tiling window managers are happening right now.
Niri is incredible, and has completely eliminated the mildly infuriating bin-packing and layout-optimization problems that TWMs exhibit, without sending me back to the floating WM dark ages. I wish Niri had existed like 10 years ago, but I'll accept it existing now as plenty good enough.
anyway, if one of the majors tiling wm managers struggling to share specific window it looks like it could be more edge cases like that. Probably, I can deal with those things but I fully understand struggle of this article author so just wanna upgrade to it when possibility of struggle will be minimal for me.
If you want to maximize all windows on run, niri can do that with a rule. It then becomes like a monocle layout where you can use swipes/keyboard/scroll wheel to navigate between maximized windows. I don't know of any DE that will run all windows maximized by default.
Too bad I no longer have an 800x600 netbook. Niri would be perfect for it.
and how does niri do it? a workspace is shared among all monitor, or it's one workspace per monitor?
Can you name any specific features you are considering as innovative?
I'd also like to see container limit rules to enforce stacking after meeting a threshold (functions as a hard cap on tiles-per-workspace), and native support for Vimium-style shortcuts for every UI element on the screen (from jwno), but I could probably live without these.
I wouldn't call these particularly innovative features, in fact they are pretty low hanging fruit.
What is dynamic offset? And what are you missing from the existing layouts the existing dynamic WMs already deliver?
> and native support for Vimium-style shortcuts for every UI element on the screen (from jwno), but I could probably live without these.
Isn't this impossible with Linux, as the WM has no control over the application on that level? Maybe through accessibility-settings you can gain them on a per app-basis. But this seems more a problem of Desktop Environments than Window Managers.
I only bring this up because I have seen a dozen or more tiling WMs come and go over the past 20 years, many of which were touted as being "the future." The reality is that the most productivity-enhancing features from tiling WMs were integrated into all the major window managers ages ago, and pure tiling WMs will forever be a niche product.
That means to use them effectively you're going to need to invest a lot of time and effort for realistically incremental gains in productivity, and in return you get the side effect of niche products like these having a lots of rough edges.
It's their superpower, and also they tile if you're into that. I never fell into a particularly useful workflow with tiling window managers myself, but as an invitation into the world of alternative lightweight Linux window managers, it's one of the most powerful demonstrations of the things Linux can do great.
I initially thought that an even better WM would be in the realm of an real-time strategy game camera: an infinite 2D canvas with "keybindable" locations+zooms. Niri has convinced me that my idea was too complicated, and it hits the perfect spot between functionality and usability.
It's like technology gifted to us by aliens from the future.
I have a laptop, 24" centered horizontal centered and a 24" vertical monitor and do a vertical half split for Spotify/teams/shell/outlook, with docs on the laptop screen and ide on the main window full screen. And virtual desktops for design/research, dev and personal.
Sticking with the standard monitor sizes instead of 4k or ultrawide makes screen sharing way simpler as well!
Small gripe, Modern UI design with 10px of padding around everything means most apps and pages HAVE to be full screen to get anything done.
They follow ubuntu releases, kind of. The downside, they went all in into their new desktop env - cosmic, and until they release it they won't move on from 20.04..
I really loved the tiling feature in PopOS 20.04 which came out of the box. But then I bought a new laptop, and had to move to arch to use it..
https://extensions.gnome.org/extension/4548/tactile/
I am an i3 convert, but I feel this is very useful, if you don't want a full-blown tiling extension, but want some of the convenience of tiling, this is such a simple solution!
Perhaps the biggest usage difference I'll make switching between a floating and tiling window manager is how I swap windows in those positions. In the tiling case I'll create tabbed containers and position the container tiles accordingly. Then any time I want to switch it's selecting a tab in the container. In the floating use case I just switch and position individually. Most of the time the tabbed container is the easier workflow, rarely the floating one can be a better fit - just depends on what exactly I'm doing at the time.
Overall the difference is relatively tiny and what I really end up wanting to get close to regardless of the tools I'm using is something like that Windows 10 beta period where you could put different applications as tabs in the same window, have the workspace/zone based tiling gestures + shortcuts, but have new things just default to floating windows until I assign them.
In the end... so long as I can position the window somewhere within 2 seconds it really doesn't matter much.
My key bindings are a little different because I use the defaults in Spectacle to do it. More than a decade like that. Program's discontinued but still works and has never given me so much as one problem this entire time, so I'm going to keep using it until it stops working.
https://support.apple.com/guide/mac-help/mac-window-tiling-i...
That thing works for me. Horses for courses, YMMV.
If that's being a cavemen, I'm a proud one at that.
That and the apple touchpad to swipe three fingers left and right to switch desktops (and different machines as one desktop is remote desked into a windows box and another terminal+tmux session to a linux box).
I really love it so far.
I only use tiling on my 21:9 display.
For me the number one thing is having fixed shortcuts á la Super+[0-9] to go to specific windows / workspaces / essentially a specific program. If I can have that, and additionally solving the "worskpace management" problem as TFA described, I'm sold!
Does it make sense to use "workspaces" like this with Niri? For example, one workspace with the browser, one with the editor, one with several terminal columns, and so on. I would need to "switch" (immediately, without animation effects, please) e.g. from "browser" to "terminals".
Niri is, however, very pretty from a technical standpoint. Modern Rust codebase, good code structure, very easy to understand and start hacking.
On laptop, it's either full width or 1/2 widths depending on the task, on the ultrawide it's 1/3rd width or full width for editor with internal column splits.
I think what always ends the experiment is that once I reach a certain number of windows, it can be more challenging to manage them if you haven't gone deep enough down the rabbit hole to properly configure workspaces, layouts, etc.
I just fired up Niri, and in 10 minutes I already feel more comfortable than I have with other tiling window managers. It feels immediately intuitive, and the mouse integration is excellent. Maybe it's too early to declare victory, but this really truly looks like exactly what I've been wanting/needing for years. I'll judge how good it is by how long it takes me to think about going back to Xfce ;)
> Naturally, instead of figuring out what library made a breaking change and spending four hours running git bisect, I decided to throw nearly a decade of muscle-memory and workflow refinements out the window.
My biggest issue is that I keep “losing” windows. I open them in a deeply nested stack, do something else and forgot I already had opened the window.
It also happens with sway to some extent but it’s a lot easier to scroll through all workspaces.
It would be nice to have something like a “window map” bound to Alt-Tab.
FWIW I've got a niri IPC / bash / jq abomination that emulates run-or-raise functionality and works probably better than the original RoR. It cycles through windows matching a particular appId and starts one if one doesn't already exist. That, alongside rofi(wayland) as a fuzzy search nav for all open windows, made a huge difference to me.
Thanks for sharing!
Recently I had a good introduction to the scrollable WM experience on GNOME with the PaperWM extension: https://github.com/paperwm/PaperWM
It does suffer a bit because it’s not built within the gnome environment. So niri is missing a few things that gnome provides “for free.” Niri leaves it up to you find replacements for some pretty basic functionality.
Some things it seems to be missing:
- Desktop notifications - App launcher - dock or any sort of list of running apps. - Xwayland (for seamlessly running x11 applications)
All of these functions must be provided by other separate tools that are not included with niri.
My biggest complaint is the lack of clipboard synchronization between x11 and Wayland. I guess that gnome handles this automatically but it’s not so in niri - Wayland apps have independent clipboard and inability copy paste between Wayland and x11 is very annoying.
There are workarounds but none that I’ve tried so far are satisfactorily convenient and reliable.
Conversely, Sway, Niri, Hyprland, i3 are bare window managers. They do not include the suite of tools and it is left up to the user to build their environment as they wish. Fortunately thanks to some defined (FreeDesktop.org & Wayland are big) and defacto standards there is a reasonable degree of interoperability for tools. For myself I pull a decent chunk of the XFCE suite into my Sway config to make my very own, special little environment. A environment that apparently no one else can even begin to figure out how to use but at least nobody asks to borrow my laptop twice.
xwayland-satellite gives you XWayland without needing compositor integration.
I am puzzeled by the fact it took us 30-40 years to figure it out !
I'm also someone whose open browser tabs tend to grow indefinitely until I just have to bookmark and close all hundred of them or whatever, so... yeah, this entire paradigm looks extremely not for me.
The way people use it is you constantly reorder windows according to your workflow so DnD is not a problem.
> I'm also someone whose open browser tabs tend to grow indefinitely until I just have to bookmark and close all hundred of them or whatever
I agree the tab model is an horror. The problem is for most people the tabs are their browsing history, with a visual clutter.
My guess is there is an huge opportunity for rethinking the whole web browser history/tab model.
You might like the tabstash browser extension
I had some hacked together python that allowed me to yank a window in and out of the stack by name and stashed a window that was the oldest in the stack (basically an LRU cache for windows)
It "worked" but I would really have enjoyed paperwm when I was in college.
There are some things that only floating WMs do right. I have a bad habit of enjoying having a few floating (pinned) copies of a document on my screen at a time in different places to cross-reference without having to move around much.
I don't know if it's really made me any more productive, but it's a fantastic learning experience, the ergonomics are great, and there's incredible satisfaction in building your own desktop environment from the ground up.
I've used i3 and moved to hyprland (because it's pretty).
From the perspective I was coming from, I don't think it matters that much, you'll run into the same issues with any of them.
It's about understanding all the things Gnome/KDE/Xfce etc do for you, and how you can set that up differently yourself using components of your choice.
[0]: https://github.com/0intro/wmii [1]: https://github.com/0intro/wmii/blob/main/cmd/wmii.rc.rc [2]: https://github.com/sunaku/wmiirc
What has massively improved my workflow recently is vertical tabs in Firefox. I now have browser tabs I can cycle up and down through on side of my screen, and application tabs I can cycle through left and right at the top. I love it.
And since this is a discussion of linux window managers: Currently I'm using hyprland, which is great, but the one I really want to keep maturing is river. It's a very sensible WM that is nonetheless not completely hostile to fun like at least one wayland WM I'm not going to name.
environment.loginShellInit = ''
if [ "$(tty)" == /dev/tty1 -a "$USER" != "root" ]; then
exec systemd-cat -t niri niri --session
fi
'';Couldn't get what to work? Like, you switch to a VT, run
nix-shell -p niri
niri
If an interested and reasonably savvy person can't get a program to work as it claims, the problem is the program, not the user.
No 'endless scrolling' aspect, but I find it works great for managing window sizing and bopping around your windows via keyboard.
But it still feels like a plastic fork and knife compared to Niri. Really wish Apple would open up more of their desktop APIs..
I also only use a single monitor, trying to plug a second monitor in makes it work less than ideally, and I really wish there was drag + drop support like most other tilers, but for me it's not worth giving up the rest of KDE.
But actually, the launchpad repo has recent commits (or do I read https://code.launchpad.net/~compiz-team/compiz/+git/compiz/+... wrong), and so does https://github.com/compiz-reloaded. You can still just use one of those if you want - Void Linux for example has it packaged, and so does Ubuntu.
There are features Niri sorely needs: 1) 2D overview (zoom in/out), 2) enhanced meta for windows (to create window indicator [1] and window picker)
> Compare that to Gnome+paperwm (1.6GB)
Anything seems lightweight if you compare it to a DE well known for its bloat.
My WM uses 1,158K of RAM, or basically just a bit above 1M. This is a very minimal custom thing I wrote years ago that works for me.
But the previous person said "total RAM usage on boot". I was curious enough to reboot: on boot my Linux system uses 310M. That's without Xorg and starting only some very minimal services. After startx it uses about 405M.
"RAM usage" is a tricky topic. I have 32G on my machine and there's no memory pressure at all on boot, so the kernel can just allocate/cache stuff "just in case", but it doesn't necessarily need all that memory to allocate.
How much is your X server process using? Because a Wayland compositor has to be both the display server and the WM in one. Comparing OpenBox alone to Niri is incomplete and incorrect, you have to compare OpenBox+Xorg+(xcompmgr or whatever frame-perfect compositor) to get a 1:1-ish comparison.
A minimal Niri functional environment is similar to IceWM in RAM usage. I used to run antiX in VMs.
I'm still using i3, which is just barely good enough to work.
I miss Notion, which was unfortunately too flakey and unstable to continue using, but that had one property which it looks like Niri preserves -- opening a new window will never cause a resize event. Notion is perhaps even stronger because there is no infinite canvas; opening a new window will never cause a re-layout. It will always open in a tab or a blank space. Similarly, moving windows won't cause re-layout actions; it will just move them between tabs of existing frames.
My i3 configuration tried to preserve this -- it tries to make everything tabbed by default so that moving windows will just move between tabs rather than into new blanks spaces and cause a relayout action, but sometimes, for some reason, it just ... does not, and instead opens a new split.
I tried to make xmonad work but I'm not good enough at Haskell to figure out if it was even possible to configure it the way I want.
And to my pleasant surprise, it seems like there may finally be an AwesomeWM alternative for Wayland now! (Pinnacle)
sway 1.10 is from october, 1.10.1 is a bugfix from late january. Since they're talking about git bisect, I imagine they might be running master (i.e., bleeding edge) instead of stable releases...
Coming in with a prepared and easy reproduction and a filed issue makes quite a difference in the response you'll get.
(For the record, I don't experience anything matching what they describe on master right now, but the post was more about PaperWM vs. tiling UX so that doesn't matter that much.)
Otherwise it is the perfect endgame UX for me. Regardless of screen size or form factor. I never thought I'd find something that I liked better than i3/sway, but those subtle niri animations, at double speed? On a high refresh rate monitor, w/ amdgpu? Ahh. Chef's kiss <3
I knew I prefer manual tiling since the very moment I tried wmii. It was the first time tiling made sense to me, and it was a major productivity booster on my 12" laptop. On such small screen I can't care less about all those spiral, bsp and other tiling schemes automatic twms offer.
I really liked Paper WM with Gnome, but it had lots of little nits that made it frustrating to use (but it did a very admirable job for a Gnome shell extension), and I went back to Sway.
I use (and pay) for the magnet app, I don't like the native fullscreen functionality or split screen options.
Aerospace has a similar resizing glitch as PaperWM.spoon: resizing one direction ends up looking wonky if you do it fast enough. It’s noticeable at the end of the smooth scrolling demo. That must be a macOS thing…
I may check out PaperWM.spoon at some point but realistically I’ll set up a VM and try out Niri
That said I really like the approach to tiling from niri and others. It eliminates pretty much all downsides of tiling WMs IMO
Overall, I deeply prefer i3 to gnome but the "everything gets resized" pain point is very real. Particularly when getting on a lot of calls with Zoom and the "notifications" seem to bypass the build in notifications on the system, instead treating each Zoom notification like it's own window...amplifying the problem.
I'm going to have to give Niri a try.
default_floating_border none
# make sure pavucontrol is floated; use xprop (cli) to get window title/class/etc
for_window [class="Pavucontrol"] floating enable, resize set height 512, opacity 0.3
# https://faq.i3wm.org/question/61/forcing-windows-as-always-f...
I find standard layer style VMs work better for desktop development. Same with being a daily driver. More dynamic moving parts with applications opening and closing ore often.
Hot take: the way clipboard functionality is implemented seems pretty “odd” to me, especiallly on Unix but some of the legacy probably goes all the way back to old school Mac OS or maybe even to xerox parc. In modern times, Neither Xwindows nor Wayland have done a lot to fix past mistakes. Wayland has done a lot, however, to expose the weaknesses in a very antiquated design.
It says “based on” in the README, which could just mean “inspired by”, but it’s also in the license so I thought that it was an actual fork. Looking at the actual history would reveal the answer, but idk, works basically the same.
defaults write -g NSUserKeyEquivalents -dict-add \
"\033Window\033Move & Resize\033Left" "@~\\U2190" \
"\033Window\033Move & Resize\033Right" "@~\\U2192" \
"\033Window\033Move & Resize\033Top" "@~\\U2191" \
"\033Window\033Move & Resize\033Bottom" "@~\\U2193" \
"\033Window\033Fill" "@~F" \
"\033Window\033Center" "@~C"
I use all of those except center, plus Cmd+Ctrl+[left, right] for top quarters left and right, and Cmd+Ctrl+Shift+[left, right] for lower quarters left and right.
Thanks!