Niri: A scrollable-tiling Wayland compositor(github.com)
github.com
Niri: A scrollable-tiling Wayland compositor
https://github.com/YaLTeR/niri
39 comments
>when Vision Pro becomes trendy
Vision Pro or its copies are unlikely to be unlocked enough to run user supplied linux.
Vision Pro or its copies are unlikely to be unlocked enough to run user supplied linux.
Vision Pro perhaps, but companies like Lenovo are already working on VR glasses you plug into a laptop or portable console (the Lenovo Legion had marketing materials leaked that showed them).
The Vision Pro concept is hardly new, of course, and there are already various window managers that will work with existing VR headsets. All someone needs to do is bring out a portable PC with the right form factor. I imagine taking the controllers and the touch screen off a Steam Deck would make for something you could quite comfortably wear, though you'd want a better battery/power plug design than what Apple has in mind.
The Vision Pro concept is hardly new, of course, and there are already various window managers that will work with existing VR headsets. All someone needs to do is bring out a portable PC with the right form factor. I imagine taking the controllers and the touch screen off a Steam Deck would make for something you could quite comfortably wear, though you'd want a better battery/power plug design than what Apple has in mind.
Yes, but I meant the trend set by Vision Pro may spill over to similar (commodity) hardware, and we may need to interact with 3D Linux “desktop” in the future.
Finally, I have been waiting for this for so long I considered writing my own! I do believe scrolling tiling is a better mechanism than regular tiling, and would work really well on mobile devices.
Have you seen PaperWM [1]? It runs on top of GNOME as an extension, so you get all the benefits of a fully fledged and supported DE, and it is quite a well done implementation. I've been using it for a few months now, works very good.
[1]: https://github.com/paperwm/PaperWM
[1]: https://github.com/paperwm/PaperWM
Anyone questioning the usefulness of this method probably don't need it. Although I haven't tried Niri itself but through this thread I got introduced to paperwm and been using it for the last 5 days and I don't think I'm going to need anything else. At some point I had real plans to make a sophisticated sway config based on my needs (and a couple of ideas I had) and I have found this solution to be perfectly inline with my ideas. My problem with TWM is that I don't need small windows because I use a small laptop and cutting the height in half is not an option. My main idea was every windows should span to full height and have meaningful width with an easy way to navigate between them and these STWM seem to be pretty on point. With just limited options to chose (when resizing a window) changes can be made in seconds (I mainly only use 4 default sizes 38% 50% 62% 100% width all spanning to take full height of the screen) Before I had to alt-tab to infinity trying to reach my desired window (I have disabled dock and top bar in Gnome and maximizing for me is the same as full-screen) and thus my greediness to use all pixels of my screen made navigating with more than three or four windows impossible. But now I have my solution. I wonder how other people are using these because I understand my use case is kinda crazy and to some extent stupid.
Is there a reason for so many tiling Wayland compositors? Are they simply easier to do? X11 always had a plethora of window managers, but really few of them where tiling. With Wayland tiling seems to outnumber stacked.
Tiling became popular and there was growth in X11 tiling window managers, afterwards people started writing them for wayland. Tiling wms have become important aspect of productivity for some people.
Yeah not to detract from the linked project (it’s one of the more interesting of its type) but the rarity of floating Wayland WMs is odd. With X there’s tons of options for building a minimal traditional floating window desktop, but that has yet to become true for Wayland.
> the rarity of floating Wayland WMs is odd
I imagine most Linux users will be on either KDE or GNOME+Mutter. People who don't use that are likely to be into low-spec desktop environments (XFCE and such) or niche solutions (i3 and friends).
There are niche stack window managers (labwc/Liri shell/Wayfire) but they don't have quite the cult following tiling WMs do.
I imagine most Linux users will be on either KDE or GNOME+Mutter. People who don't use that are likely to be into low-spec desktop environments (XFCE and such) or niche solutions (i3 and friends).
There are niche stack window managers (labwc/Liri shell/Wayfire) but they don't have quite the cult following tiling WMs do.
> With X there’s tons of options for building a minimal traditional floating window desktop, but that has yet to become true for Wayland.
X window managers are a lot simpler than Wayland compositors, even including helper libraries, so I expect this to remain true.
X window managers are a lot simpler than Wayland compositors, even including helper libraries, so I expect this to remain true.
> X11 always had a plethora of window managers, but really few of them where tiling.
There's a lot more small and obscure tiling WMs than stacking ones for X11 as well.
There's a lot more small and obscure tiling WMs than stacking ones for X11 as well.
Gnome and KDE have kinda nailed it, don’t you think? I mean, what are you going to bring to the table by writing a stacking window manager? There are infinite ways to tile windows; one way to stack them.
> There are infinite ways to tile windows; one way to stack them.
That's not really true, though; AFAIK KDE/GNOME don't implement tabbed windows or the ability to stick them together.
That's not really true, though; AFAIK KDE/GNOME don't implement tabbed windows or the ability to stick them together.
KDE did implement tabbed windows IIRC but it was removed for KDE5 due to lack of maintenance. I think they are trying to bring them back.
[deleted]
What's the point of having two 67%-width windows next to each other?
For me (been using paperwm since ) the real point of having them is that a lot of windows don't really benefit from extra width (heck even hacker news website shows white bars in the sides) so by having 67% windows not only I'm not losing anything but now I have a context of which windows are to left and right of currently focused window and that helps me to remember where everything is located in this big wall of windows. I remember installing something using apt and looking for when it's going to be finished in the remaining 33% of screen (This use case is not that prevalent and is really limited in how much information of the other window can be perceived)
Another benefit is how sick it looks (In my opinion). Anyone looking would be interested.
Another benefit is how sick it looks (In my opinion). Anyone looking would be interested.
As an example, I usually keep my code editor maximized, with a 67% gitui terminal to the left and a 67% "compile & run" terminal to the right. This way nothing is too small.
And then I use workspaces for different groups of windows, i.e. messaging apps, the browser, and different projects all go on different workspaces.
And then I use workspaces for different groups of windows, i.e. messaging apps, the browser, and different projects all go on different workspaces.
How is that useful? You only see half of the other window. Why not resize it to fit 33%, or fullscreen them both?
I use xmonad so I'm well used to tiling, I just don't get why you would want to have a view into only half of a window.
I use xmonad so I'm well used to tiling, I just don't get why you would want to have a view into only half of a window.
You could fullscreen them, yeah. Just for gitui on my monitor, I find that 67% is both sufficient and enough, and keeping a little bit of the other window in sight helps maintain spatial context.
Besides, when it's something like runtime logs in a terminal, I sometimes keep the terminal maximized (to avoid line wrapping), but only leave it peeking out, so that I can switch to it if I notice something strange in the left side of the output.
Besides, when it's something like runtime logs in a terminal, I sometimes keep the terminal maximized (to avoid line wrapping), but only leave it peeking out, so that I can switch to it if I notice something strange in the left side of the output.
Okay, to each its own, but to me it still sounds a bit like a crazy workaround.
Not all of the window is usefull all of the time. Sometimes only the terminal half of the IDE is, sometimes just the editor half is. Same to the browser, sometimes you only need to look at the console and not the website (while testing something over the IDE). Resizing windows is actually way more annoying than just aranging them the right way so you can alway trigger the useful half.
I think most tilling WMs fails to realize how annoying windows that keep changing size are. If they do, the entire concept of automatic tiling seems way less useful.
I think most tilling WMs fails to realize how annoying windows that keep changing size are. If they do, the entire concept of automatic tiling seems way less useful.
Your problem is that you don't divide these windows. The terminal is obvious, and IIRC the browser console can be its own window.
That's not a "problem", it's a choice. Other examples where your "solution" isn't applicable is any code editor/video editing software (any software really) with multiple panels. Software generally don't render as a bunch of floating windows, they render a single window with multiple panels.
A choice made by whom? For who? Not you. That's why you have to resort to some bizarre layout, with some magic 67% size concerning both WM and individual windows' panels.
A code editor does not need a terminal, because everyone already has a terminal that is not restricted into one IDE window. Do you run tmux inside your IDE's terminal? Do you never use any other terminal? You shift the goalpost to video editing, what is the specific double-67% requirement now?
A code editor does not need a terminal, because everyone already has a terminal that is not restricted into one IDE window. Do you run tmux inside your IDE's terminal? Do you never use any other terminal? You shift the goalpost to video editing, what is the specific double-67% requirement now?
> You shift the goalpost to video editing
Did I not make a generalization that software UI often involve multiple panels in a single window? Just quit chery-picking arguments and think about that, and the fact that PaperWM exists, and again how anoying automatically resizing windows are.
Hey turns out I did say things other than terminal and video editor!
Did I not make a generalization that software UI often involve multiple panels in a single window? Just quit chery-picking arguments and think about that, and the fact that PaperWM exists, and again how anoying automatically resizing windows are.
Hey turns out I did say things other than terminal and video editor!
You cherry picked those specific examples yourself!
Floating WMs also exist, and all kind of unergonomic setups exists, I'm just questioning your reasoning.
Floating WMs also exist, and all kind of unergonomic setups exists, I'm just questioning your reasoning.
Is scrollable tiling better than regular tiling in a laptop screen?
I personally find it better because, unlike regular tiling, you're not constrained to the screen size. I.e. if a 50% window width is too small, I can tile together several 67% or even 100% wide windows, and just scroll between them.
How is that better than alt+tab? Do you really benefit from being able to see both at the same time if you have to constantly adjust the scrolling manually? My intuition is that tiling is that scrolling negates any benefit tiling had, since it reintroduces the mouse as a core aspect of window navigation.
If you have more than say like 5 windows, trying to navigate to the desired one can be hellish. Here every windows have it's own place and by remembering it, you can navigate to it very easily. Scrollable and traditional Tiling are not related at all (at least for me) and try to do different things.
I've been using paperwm for a couple of days and my laptop track-pad doesn't even support three finger scrolling so I'm currently using keyboard to navigate.
I've been using paperwm for a couple of days and my laptop track-pad doesn't even support three finger scrolling so I'm currently using keyboard to navigate.
Alt+Tab is in most-recently-used order, whereas with scrolling it's a spatial kind of system.
> since it reintroduces the mouse as a core aspect of window navigation
Not really, why? You switch between windows with binds, just like in a regular tiling WM. Mod+Left/Right (H/L) goes to the window to the left/right, etc.
> since it reintroduces the mouse as a core aspect of window navigation
Not really, why? You switch between windows with binds, just like in a regular tiling WM. Mod+Left/Right (H/L) goes to the window to the left/right, etc.
That makes sense, thanks!
Love this idea! What determines the width of a window?
I will describe how PaperWM works; I think that behavior makes a lot of sense.
There are preset widths (by default: ~33%, 50%, ~67%) which you can toggle between with a key, plus a 100% "maximized" width that you can toggle separately. This works out pretty well from my experience and gives you the convenient 33/67 and 50/50 layouts (or 33/33/33 on ultrawides).
The initial window width is what the window wants. So the window is free to use any size on creation, then PaperWM expands it to full height with the same width that the window had selected.
There are preset widths (by default: ~33%, 50%, ~67%) which you can toggle between with a key, plus a 100% "maximized" width that you can toggle separately. This works out pretty well from my experience and gives you the convenient 33/67 and 50/50 layouts (or 33/33/33 on ultrawides).
The initial window width is what the window wants. So the window is free to use any size on creation, then PaperWM expands it to full height with the same width that the window had selected.
PS: I am not affiliated with the repo in anyway, but think that scrollable-tiling should be better known.