I've been using i3 for 7 years now, and my immediate response to the scrolling thing was "why?" and after reading your comment, I'm still trying to understand. As one would expect for any tiling wm, the screenshots only show how pretty it can be, and don't really illustrate how it helps with productivity.
Would you mind going into more detail on what actually happens when you move horizontally? What happens when you have a fullscreen editor, then slide over to a half-screen browser? Do you only see half the editor, or does the editor get squished?
One thing I desperately want is a tiling wm that is also a browser. Like if surf ran a practical engine and was more deeply integrated into dmenu.
I was using i3/sway for years previously as well (and some awesome, qtile before that). The big difference is window size.
Generally I believe most people like to order their workspacesroughly by topic, e.g. all work related Windows on one, browser or on another, some also do all terminals on one... Now with sway/i3 I often found myself in the situation where I was e.g. on the "browser" desktop and you read something you quickly want to try in, e.g. ipython, or you are working on a latex document and want to briefly open a PDF. In i3 that would reduce the size of your original window, so you end up switching to a workspace (or you manually switch to tabbed tiling) for me the mental overhead was significantly higher and I was ending up creating more and more workspaces just to hold temporary terminals.
This is actually related to why I switched to i3 in the first place, I just felt vertical tiling is the only tiling that makes sense in 95% of the cases and that just worked best in i3. But that comes at the cost that you are limited to only 3-4 tiles per workspace (depending on screensize) now in niri I have infinite theoretically. Which means I spend less mental overhead when I want to open another window (which is really thebgoal of tiling wms in my opinion, reduce thinking spend on window management)
Thank you for the explanation! Between your explanation and a Youtube video I found of someone using it, I think have a grip on the "why" now. Interestingly, it seems like I might use i3 a little differently than you did. A single working context for me can span many desktops, and I just work in a way that keeps my number of concurrent working contexts low. I only ever have 1-2 programs on any given desktop, and even 2 is unusual. I keep every window in tabbed mode. When I need a scratch "thing" (nautilus, terminal, localc, whatever) it opens as a new tab. If I need it side-by-side with that desktop's primary window, I pop it out using mod4+shift+left/right. This accomplishes a similar thing to that Niri is getting you, just with different ergonomics. It probably helps that I have good habits around closing unused tabs / programs.
Yes it seems like you're using i3 quite differently. I agree that if you good discipline about opening and closing windows in the right workspace/tile i3 can give you a more structured layout. I just found for myself even if I tried I could not keep the discipline up (I doesn't help that I often work on several things at the same time).
I think that's the beauty of tiling WMs (and I consider scrolling WMs a subset), you can really adjust them to suit your work flow even if work flows might be very different. In contrast stacking WMs seem to be more a lowest common denominator type thing. They work with every workflow, but suboptimal.
I think my i3 "style" came from using a 12-inch thinkpad for many years. The small screen size and low resolution force you to work in certain ways. And if I had left 100 Firefox tabs open on that machine's second-gen mobile i5, I think it would have melted straight through the desk.
Re. pane size, it's normal tiling behavior. Panes can be take the full screen or some percentage (I like 1/2, 2/3, and 1/3). If the widths add to 1, both panes fill the screen.
If the widths don't add to 1, there are two possible behaviors (configurable). Either the newly focused pane adheres to the size of the screen (e.g., scroll right from the full screen editor and the half-screen browser is on the right border with half the editor visible), or the newly focused pane centers on the screen. I prefer the first behavior, but I make significant use of the "center pane" keybinding.
The Video Demo section in the README gives a pretty good demonstration of this behavior in the first 10-15 seconds.
Edit: To add to this thought and address some comments elsewhere about losing windows, I use "struts", which show P pixels of the panes to the left and right (when they exist) of the current view as a visual aid/reminder of where I am in the ribbon. These reduce the size of the tiled section of the screen and the calculation of pane size accordingly.
The WM has no job being the browser, but yes we should be able to run firefox without tabs like it's surf (and stop doing part of the WM's job). But you cannot practically do that.
> yes we should be able to run firefox without tabs like it's surf
Can't you? You used to be able to show the tab bar only when there was more than one tab; I guess that has disappeared?
You can do this: Put this code into your userChrome.css file:
#tabbrowser-tabs .tabbrowser-tab:only-of-type, #tabbrowser-tabs .tabbrowser-tab:only-of-type + #tabbrowser-arrowscrollbox-periphery { display: none !important; }
#tabbrowser-tabs, #tabbrowser-arrowscrollbox { min-height: 0 !important; }
Zen browser (which is derived from Firefox) does a really good job of making this the default (at the expense of mainly supporting vertical tab lists, which I've come to love).
just open new windows instead of tabs. Or am I missing something?