I don't have any results for Windows or macOS yet unfortunately. I wanted to run these tests on Windows eventually, and include things like cmd.exe and the Windows Terminal. Maybe when I get around to re-benchmarking a wider range of terminals. Mac would certainly be interesting to include, but I don't have access to any of those.
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.
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.
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.
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.
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?
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!
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.
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.
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.
Whenever I tried streaming coding on Twitch I found myself being much less productive than normally due to constantly having to pay attention to the chat and whatnot. Actually for me even having something like a chat open without paying attention seems to significantly decrease the productivity, it's as if a constant part of my brain gets dedicated to the potential viewers regardless of whether it's being currently occupied by the said viewers.
That can be an issue, but also if you're streaming then you're probably doing so in landscape and having your display configured in portrait just seems so much more productive.
You can compensate by having a much higher resolution landscape display where certain windows are portrait, but the text won't be that readable on stream without dynamic zooms.
I think the real value is that if you're having motivational issues and streaming gives you more consistent motivation then it may offset the downsides. Writing some code in a suboptimal environment is better than writing no code in an optimal environment.
I don't have any results for Windows or macOS yet unfortunately. I wanted to run these tests on Windows eventually, and include things like cmd.exe and the Windows Terminal. Maybe when I get around to re-benchmarking a wider range of terminals. Mac would certainly be interesting to include, but I don't have access to any of those.