Retain Workspaces on Primary Display Only as an Option

paperwm / PaperWM

Tiled scrollable window management for Gnome Shell

GNU General Public License v3.0

2.96k stars 125 forks source link

Retain Workspaces on Primary Display Only as an Option #932

Open starr-dusT opened 3 weeks ago

starr-dusT commented 3 weeks ago

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!

jtaala commented 3 weeks ago

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

rawkode commented 2 weeks ago

Potential duplicate of #216

starr-dusT commented 2 weeks ago

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

jtaala commented 2 weeks ago

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.

starr-dusT commented 1 week ago

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!

jtaala commented 1 week ago

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