The question is what are you going to do if you want to launch an app relevant to the current workspace (let's say Gimp), but it's not important enough to be visible with the other windows in that workspace (editor, terminal, browser) or it doesn't fit.
Overflowing Gimp onto another workspace because of this is the main cause of workspace spam that a scrolling WM solves.
If you're working on more than one project (so, workspace 1 2 and 3 are fully utilized), where does this overflow workspace even live? And what if each workspace also needs its own Gimp instance?
There are certainly solutions to this in every WM, but the scrolling WM solution is a really simple one that never makes you ask the question of where to put something: workspaces have an offscreen overflow area.
Another way of thinking about it is: sway would be instantly improved for me if it also had a per-workspace overflow area, like maybe if every workspace had its own scratchpad that I could tile windows on, and I could reach it by moving focus into it kind like moving between monitors.
I open Gimp on a scratch workspace and immediately have my WM jump to it. How is that different from having to scroll to it?
If I need a Gimp in every workspace I just open a Gimp in every workspace where I need one. Or even customize my Xmonad to show specific Gimp instances on select workspaces.
Again, how does the scrolling layout do me ANY favors here?
Sure, Niri takes away the question of where to place it, but it definitely doesn't help with "Where the fuck is that one window I opened and how do I find it?" I'd rather just quickly select all my workspaces in the worst case than selecting every workspace and THEN scrolling through all the windows.
If you really need THAT much overspill on a workspace I would personally rather stop and re-evaluate the workflow instead of just spilling tons of windows all over the workspace.
It feels like if you'd sit down and re-evaluate the workflow and the setup, those problems could be solved almost without a WM.
> If I need a Gimp in every workspace I just open a Gimp in every workspace where I need one.
Sticking with the workspace-per-project scenario:
What if there's no room in the workspaces that need Gimp? Or what if you only want Gimp occasionally, so you don't want it to fight for layout with your important windows in each workspace.
The downside of scratchpad is that you'll have many Gimps there, and they're disconnected from their related workspaces.
> Niri takes away the question of where to place it, but it definitely doesn't help with "Where the fuck is that one window I opened and how do I find it?"
In the workspace per project example, it's "my project foo Gimp is in the project foo workspace's overflow".
With something like i3/sway, you'll probably hide gimp in a tabbed/stacked container in some node in the workspace tree, but that's fiddly and kind of a hack in this example.
As for "where the heck is this window at all", I like mod-tab to MRU enumerate windows globally. This is a nice solution in any WM/DE.
> If you really need THAT much overspill on a workspace
We're just talking about an extra window here in a multi project setup which is something I run into dozens of times a day. You'll find a reference to this in every "I switched from i3/sway to niri" blog post. https://ersei.net/en/blog/niri - I'd say it's the main trade-off.
> Sure, Niri takes away the question of where to place it
We can probably just end it here, because that's the utility of a scrolling WM and you saw my point.
> What if there's no room in the workspaces that need Gimp? Or what if you only want Gimp occasionally, so you don't want it to fight for layout with your important windows in each workspace.
If I can't be bothered to use another workspace for Gimp, then I'll open it as a stacked window in StumpWM. So no fighting over space.
If you seriously end up with 5+ GIMP instances and 5+ projects, then I have to say: there is no way you work on that many projects at once. If you do, then that sounds more like a workflow problem.
I usually only have one, maybe 2 projects open, and a browser or two somewhere, maybe a terminal if I need a non-Emacs terminal. If you got 3-4-5-6 projects going at the same time that really is a project management problem I'd wager.
Might also be that I just have tabs or "workspaces" in my Emacs.
But I just can't see the advantage of the scrolling to just plain workspaces. The scrolling to me just adds one more indirection of having to remember where something is. It adds a new level to the navigation tree.
We can probably end that then, because you saw MY point. Whatever that means :D
Tried Niri before, but it seemed more to adhere to fancy animations than actual improvements.
Overflowing Gimp onto another workspace because of this is the main cause of workspace spam that a scrolling WM solves.
If you're working on more than one project (so, workspace 1 2 and 3 are fully utilized), where does this overflow workspace even live? And what if each workspace also needs its own Gimp instance?
There are certainly solutions to this in every WM, but the scrolling WM solution is a really simple one that never makes you ask the question of where to put something: workspaces have an offscreen overflow area.
Another way of thinking about it is: sway would be instantly improved for me if it also had a per-workspace overflow area, like maybe if every workspace had its own scratchpad that I could tile windows on, and I could reach it by moving focus into it kind like moving between monitors.