Tiling WMs are dead. Long live tiling WMs. Scrolling WMs like Niri/Paperwm are where it’s at now.
Conceptually, it's like an infinite 2D canvas windows, divided into strips (strip is a workspace), and you then scroll through an infinite ribbon of windows in each strip.
Seems interesting, but also slower and less flexible than traditional tiling WMs (least of all because of the slow scrolling animations, but also because it seems to prefer scrolling instead of jumping-towards).
Like most of the 'tiling with gaps' patches I see, these feel like trying to look fancy without necessarily delivering big value. I'd be interested to hear why people want a scrolling WM. Is it merely more visually pleasing?
You can get similar functionality with tabbed windows, but I'm still trying to decide which workflow I prefer; scrolling feels a bit more "organic", while tabs are superior for density.
This is opposed to a traditional tiling WM where you'd either need to open the app in another workspace, use some stacking feature or worst of all shove the new window into the current view by resizing some other window(s) which is often not ideal.
I never want to / have to wonder where any particular window is. Every app will always open on the same workspace, in the same position that I define + a scratchpad workspace for random one-offs that I keep floating. I'm only ever 1 key press away from exactly what I want. I know that ctrl+b gets me my browser, ctrl+t gets me to my terminal(s), etc. I don't even think about the workspace numbers or layout beyond initial configuration. Zero animations, instant switching.
In your example, if I'm on one workspace working and I need to open Gimp, I press my keybind for Gimp and it opens on the scratchpad and switches to it immediately.
It takes a lot of initial config and tweaking as you go along but once settled it's the most efficient way I've found to manage windows, in that, the windows manage themselves i no longer have to think about them at all.
I'm often working on 3+ codebases or projects at the same time, each project has a browser window with associated tabs, an instance of an editor, several terminals. So they get a workspace. "Switch to browser workspace" makes no sense if there are 3 instances of the browser open, especially when I want the browser next to my editor for live reload/API docs.
In Niri, you just have these open in the each workspace off to the side. And you know exactly where each one is.
In your example, you either have to flip through multiple Gimp instances in your scratchpad or you use tab/stack containers to tile them in to existing workspaces. But you are multiple keystrokes away now because you have to go to the container and paginate through it.
I use Awesome Window Manager and one feature I like about it is this:
Say I've got my terminal in workspace 1, Firefox in workspace 2, and Emacs in workspace 3. There are often times I need to use either the terminal or Emacs (or both) while viewing a website. So with a keystroke, I can tell it to combine any two or three workspaces and all the windows are shown tiled together. In a sense, it creates a new temporary workspace with all 3 windows. As soon as I leave this workspace, it restores it to the original configuration. No need to move windows from one workspace to another and remember to move them back.
This is the one feature that I'm really missing from Mac OS.
Mod4 + Control + 1-9
Toggle tag view.
If you press Mod4 + Control + 3 again, it will remove workspace 3 from view.
If you now just leave to go to some workspace, (e.g. Mod4 + 5), it will only show workspace 5.
Can't live without it.
Workspace 1: Browser, Email, Music
Workspace 2: Running project, editor(s)
On sway/i3 I always had these things split across multiple workspaces it could get tedious switching between them at times.
Switched workspaces I know what is on each workspace, I can switch to it, see what's there. But the Niri approach, I have to scroll through the space to see which windows are actually there.
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.
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.
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.
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.