paperwm
Retain Workspaces on Primary Display Only as an Option
I really like the idea of the extensions, but have issues with multi-monitors. I assume it is part of the fighting default behavior of Gnome, but windows flash/appear/disappear on the other monitor when workspaces are changed. I find this distracting and would like to restrict workspaces to a single screen (as-is one of the default multi-monitor modes in Gnome). I'd be willing to look into trying to implement this, but would like a first pass opinion if it would be an untenable add for one reason or another or perhaps I'm missing a way this can be done already. Thanks!
I assume it is part of the fighting default behavior of Gnome, but windows flash/appear/disappear on the other monitor when workspaces are changed
Very much. I'm assuming you are referring to coming our of Gnome overview? (the window flashing). We've toyed with creating our own "overview".
Supporting workspaces on primary display only is a good request. We've had basic support previously but some issues weren't resolved, so PaperWM disables that option when starting up.
Not really untenable, and could alleviate the issue you mentioned above (and would be easier than implementing our own overview).
Thanks @rawkode. I don't think this is exactly the issue they were having there. Maybe I'm being precious, but I've attached a video of what I'm seeing. This is a capture of my second monitor on workspace 2 while I cycle between workspace 1 and 3 on the primary monitor. You can see the chrome window pop in and out. I think this is expected behavior, but I haven't seen anyone explicitly mention it and that surprises me because I find it distracting. Is this the expected behavior @jtaala or @rawkode? Thanks for taking the time I really appreciate the work you all are doing.
Screencast from 2024-08-28 19-54-08.webm
Is this the expected behavior @jtaala or @rawkode?
No. Then again, you're not actually using PaperWM's workspace switching model (how are you workspace switching? e.g. what keybinds are you using?).
PaperWM has it's own workspaces switching paradigm, where workspaces are vertically stacked on each monitor - e.g. this is what it looks like:
https://github.com/user-attachments/assets/fcc54af5-46ec-4e71-bd2e-a1d84bb287a1
The default keybinds for switching to above/below workspaces are super+page_up, super+page_down. You can change those to any preferred keybinds:
Note, you can choose different switching behaviours (e.g. switch between workspace assigned to all monitors, or just the current monitor etc.
Ahh... that makes sense. I'm switching work spaces with custom key binds on Super + 1,2,3... like this:
Using the PaperWM key-binds work as expected. I might have missed documentation on that, my bad. If the built-in key-binds aren't intended to be supported this can be closed. Thanks for the help and great project!
Yes, it is intended that with PaperWM, the paperwm keybinds for switching windows is used. Although, I'm just trying to remember why we don't have keybinds to switch to workspaces directly (e.g. switch to workspace 1 etc.).
Hello,
I'm also using Gnome's shortcuts to switch between workspaces (Super+1, Super+2, etc.), which is similar to the i3/sway workflow.
I really like it, as I have workspaces dedicated to activities (1 = browser, 2 = IDEs, etc.), and I like switching directly to the one I need without having to cycle through.
With a single screen, it works well with PaperWM, and I really feel both approaches are complementary.
But with a second screen, I also face issues.
Sometimes the workspace switch but the windows from the previous workspace stay (actually I think it stays in the same PaperWM workspace).
Here's a small example, where switching between 3 and 4 doesn't work (with Gnome shortcuts), and switching with PaperWM shortcuts shows that workspace 4 is actually missing (?) :
