[alex-robbins]

Does anyone else find it suspicious that the author was using so many workspaces on sway? I have to wonder if they're not making good use of sway's tabbed and stacked containers ...

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

[the_gipsy]

> The trick to making this ergonomic is to choose what to stack vs tab

This is exactly what TFA mentions: you van remove choices via a simpler model that does not really sacrifice anything.

[alex-robbins]

Well, if you remove the choice, that can actually sacrifice the ergonomics GP described, because of one of the important differences between stacked and tabbed: directionality.

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

This is a root container whose two children are "Tabbed Browsers" and "hsplit of 'emacs' and 'a tabbed container with terminals'". (This root container is a stacking container, and the browsers' part only takes up about one title-bar-height on the screen because something in the hsplit has focus, so the hsplit gets all of the space and the actual content of the browser windows are not currently visible.) The reason it's stacking, and not tabbed, is because this way I can flip back and forth between any browser and any of the other windows with just one key per direction ("focus up" to get to whichever of the browsers was last focused, "focus down" to get back to whichever of the windows in the hsplit was last focused). Additionally, I can get back and forth between emacs and a specific tabbed term (the left-most one) with one key per direction ("focus right" and "focus left", of course), and I can get back and forth between emacs and any of the terms with 1+2=3 keys round-trip ("focus right" to get from emacs to whichever of the tabbed terms last had focus, "focus parent-wards then left" to get back to emacs). Critically, if you were to change any single one of the stacked containers in this layout to tabbed, or any of the tabbed containers to stacked, then you would be sacrificing at least one of these three properties.

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.