-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional 'standard' workspace behaviour #913
Comments
Separating the monitors to separate workspaces is central to PaperWM's design and operation ("per monitor workspaces). I wouldn't be interested in implementing this or using this approach, but would accept a PR if someone would like to work on this one. |
I would be more than happy to develop it myself, have already forked the repo and am currently trying to wrap my head around the inner workings of both GNOME Extensions and PaperWM. Could you maybe help me out with where the logic for the workspace management even is? For now I have only found the logic for creating new empty workspaces if there aren't enough. |
It's a little involved to be honest. In gnome (or Mutter), a workspace is just a collection (or logical grouping) of meta_windows. In PaperWM we control that grouping very differently than standard Gnome. In any case, there's really no central place for workspace management - we just manage meta_windows (including setting their "workspace" ids). In other words, there's really no place for "workspace management" - it's part of PaperWM tiling operations (so the philosophy and management of workspaces are at the meta_window level, which means it's part of many of PaperWM modules). |
So, to sum it up:
|
The difficulty will be in that per monitor workspaces are "enforced" throughout the entire codebase (i.e. it was designed like that from the get go - if that wasn't part of the design PaperWM would have been written quite differently). But yes, what you've written above is correct in principal. |
Ah yes, this very related to per monitors workspaces (fighting against gnome's approach). I have down to write our own |
After reading into the source code for a bit (rlly not much, will try to find more time though) I think
|
I have decided that it is not worth the effort (after trying to develop the most simple GNOME Extension for a day). I have settled on using PaperWM when on the move and only having one display, and using Forge when docked. For the switching between the two I have written the extension mentioned before. If there is any interest in that let me know, and I will publish it. |
If PaperWM is not quite what you're after, you should def give https://github.com/YaLTeR/niri a go (it's a scrolling tiling window manager that avoids some multi-monitor issues since it's not fighting against Gnome's (well really Mutter's) global window coord space and approach. |
I personally love having a full DE instead of just a WM (because I just spend far too much time configuring it when I should be doing other stuff instead), the only way I liked using a WM was with combining Plasma and I3 (back on X11). But I think I am quite happy with how I solved it. This makes me productive on the go when I love the scrolling aspect of PaperWM (because of the gestures), and I like the workspace management of Forge when docked on the desktop. |
Is your feature request related to a problem? Please describe.
I like to have my workspaces horizontally (like with most desktops and OSes traditionally). Because of that I deactivated the vertical shortcuts for the PaperWM workspace management (to switch workspaces on a trackpad I just swipe up with three fingers to get to the overview and then to the side to switch workspaces). My keyboard shortcuts too are setup this way (Ctrl+Super+Arrow). PaperWM overrides the standard behavior and separates monitors to different workspaces, which makes the usage frustrating to say the least.
The current behavior also looks weird in the overview.
Describe the solution you'd like
An optional toggle to not override the standard behavior and use the default instead. This would mean that monitors are kept on the same workspace.
Describe alternatives you've considered
I am not sure if there even are any.
The text was updated successfully, but these errors were encountered: