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".

That said I really like the approach to tiling from niri and others. It eliminates pretty much all downsides of tiling WMs IMO

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.

https://github.com/Leleat/Tiling-Assistant

https://pop.system76.com/

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..

That thing works for me. Horses for courses, YMMV.

If that's being a cavemen, I'm a proud one at that.

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...

    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!

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.

I really love it so far.

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).

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.

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 ;)

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 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.

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.)

> 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.

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.

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.

I am puzzeled by the fact it took us 30-40 years to figure it out !

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'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.

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

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.

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'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.

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.)

[0] https://github.com/YaLTeR/niri/wiki/Xwayland

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

And to my pleasant surprise, it seems like there may finally be an AwesomeWM alternative for Wayland now! (Pinnacle)

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

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.

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).

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.

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

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

[0] https://herbstluftwm.org/

(watch the bottom-right readout on the video)

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.

> Display scaling (integer or fractional) will make X11 apps look blurry; this needs to be supported in xwayland-satellite.

I use labwc currently which has the ideal workspace behaviour (one workspace shared).

and how does niri do it? a workspace is shared among all monitor, or it's one workspace per monitor?

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.

Last time I tried, a few weeks ago, it wasn't better.

The author linked their config file from the article, and it includes this:

    // Animation settings.
    animations {
        // Uncomment to turn off all animations.
        // off

No 'endless scrolling' aspect, but I find it works great for managing window sizing and bopping around your windows via keyboard.

https://github.com/nikitabobko/AeroSpace

But it still feels like a plastic fork and knife compared to Niri. Really wish Apple would open up more of their desktop APIs..

Viture comes to mind.

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.

> 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?

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...

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%.

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.

The Windows scene is definitely the place where the most interesting workflow advances in "traditional" tiling window managers are happening right now.

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.