Cinnamon Workspaces

[rcalixte]

Preface
The following pull requests were opened in an effort to separate out key bindings and keyboard menu options for workspace up/down and workspace/window selection:

• [NEXT] cs_keyboard.py, main.js, and windowManager.js: Separate the key bindings and keyboard menu options for switching workspace up/down and toggling window/workspace selection cinnamon#10989
• [NEXT] org.cinnamon.desktop.keybindings.wm schema: Separate key binding for switching workspace up/down from toggling window/workspace selection cinnamon-desktop#214
• [NEXT] keybindings.c and prefs.h: Add separate key bindings for toggle window/workspace muffin#628

Challenges
The core challenges as correctly indicated by @mtwebster are two-fold:

• the changes proposed as-is would be disruptive to users (without being able to retain the current state, key bindings would effectively be reset so that they can be independent)
• the separation of workspace up/down key bindings begs the question of whether or not the core of Cinnamon should offer more native workspace management solutions (as opposed to Applets and/or Extensions)

Ideas
This applet contains what would effectively be combined with the current state to derive additional stock functionality. The release would be done in a way that user impact would be minimal, if at all. Ideally targeted for a major release of Linux Mint (e.g. 22.0) but communicated extremely well regardless so that users of other distros (Arch, Fedora, etc.) would not face disruption.

Discussion
While trying to focus on minimizing user impact and extending the current workspace functionality, the discussion is regarding the workspace functionality roadmap for Cinnamon and any possible improvements that can be done in that space. The goal would be a clear decision with a path forward for execution.

Scope
The intended scope of discussion here is not just configuration but workspace management in general. While these pull requests are focused on a limited scope, there are other aspects for inclusion, such as the multi-monitor behavior options observed here (borrowed from the current pre-alpha COSMIC):

Thanks
Thanks to @mtwebster and @clefebvre for everything up to this point.

[corbin-auriti]

Sounds good! Separating key bindings for workspace management could be a bit disruptive, but it's a step in the right direction. Excited to see these improvements!

[adelpourmand]

At least I prefer i could assign different background for each workspace.

[rcalixte]

A different background for each workspace or for each display/monitor? If it's the latter, you can use HydraPaper for that.

[adelpourmand]

As I tested Hydrapaper, it is suitable for different display/monitor and is not suitable for different workspace on one display/monitor.