[Feature Request] Consistent workspace numbering, better navigation, and cross-monitor control (like i3)

[agjini]

Why this issue?

I’d like to summarize here a list of requests regarding the behavior, usage, and navigation of workspaces in Cosmic, with the goal of greatly improving ergonomics.

The purpose of this “umbrella” issue is to:

• Gather related requests that have already been mentioned across several existing issues but are interdependent.
• Provide a place for interested users to discuss and align their understanding of the topic.

These features relate to the use of workspaces in Cosmic, with or without multiple monitors.

Currently, these features cannot be achieved in the existing version.
The idea of pinning a workspace was mentioned here, but it only partially addresses the need.
It is monitor-specific and, more importantly, incompatible with rule number 2 listed below.

My requests are largely inspired by how workspaces are managed and navigated in tiling window environments such as i3 and Hyprland, Sway (and likely others).

These features affect two main aspects of Cosmic:

• Workspace management (is this handled by the cosmic-workspaces-epoch repository?)
• The display and behavior of the “Numbered Workspace” applet (referred to below as “the workspace list in the panel”)

Requested feature

Consistent and immutable workspace numbering (with or without multiple monitors)

Rules

1. Workspace numbering must be absolute and immutable (see below).
2. It should be possible to open any workspace directly, even if its predecessor is not already open.
   Therefore, showing the next empty workspace at the end of the list (as it currently works) should no longer be necessary.
3. Only workspaces that contain at least one window should be shown in the workspace list.
4. When closing a workspace, the numbering of the others should not change (immutability and absoluteness).
5. Workspace numbering must remain unique and consistent across all monitors.
6. Add actions to move the active workspace to another screen (up, down, left, right).
7. When switching to a workspace via the panel, the first window should automatically gain focus, just as it does when switching via keybindings.

Linked issues

• [Feature Request] Enable Workspace Switching Across Monitors (Monitor-Linked Workspaces) #187
• Workspaces can't be accessed via Super+Num or Super+Shift+Num shortcuts until they've been created #211

Feedback requested

Please, I would like to have:

• Feedback from users interested in this feature.
• Feedback from Cosmic contributors and maintainers about the feasibility of this feature and whether it aligns with the Cosmic roadmap.
• Comments on whether the rules are clearly written, and whether you agree or disagree with each of them — or if you think some are missing.

[kcodedev]

I need consistency in this instance:
I use a laptop and sometimes connect to an external display with the lid closed. I have pinned workspaces dedicated to certain applications.

• Workspace 1 = Terminal
• Workspace 2 = IDE
• Workspace 3 = Browser
• etc.

When I close the laptop lid and connect the external display these workspaces get jumbled up and I can no longer use muscle memory to quickly navigate to the workspace with my desired application.

The frustrating fix for me is to rearrange the workspaces using the Super + W view.

If I open the laptop lid while connected to the external display some workspaces remain on the external display and some move to the laptop. I guess the current approach is there are completely separate workspace settings stored for each state:

1. laptop open and not connected to external display
2. laptop closed and connected to external display
3. laptop open and connected to external display

It would definitely be nice to have the option so the first two states can be consistent.

[agjini]

I think the behaviour of workspaces when connecting or disconnecting to an external monitor is a consequence of the workspaces management in cosmic.

I've discussed with @Drakulix and currently the cosmic compositor manages workspaces by outputs (monitors). The only way to change that is to discuss with the UX team of cosmic and this is the right repository for that. Because this is a UX decision.

Would it be possible to get feedback from someone on the UX team about this topic? With explanation of the current choices behind the current behaviour.

Thanks

[istvan-andrasi]

I aggree while keeping the "workspaces span outputs" option, which is not present in i3/sway but I like it very much.

[agjini]

I aggree while keeping the "workspaces span outputs" option, which is not present in i3/sway but I like it very much.

Not sure to understand your point of view, can you be more precise?

Thanks

[istvan-andrasi]

I use the option when the selected workspace is shown on all outputs. If I switch to workspace 1, all outputs switch to workspace 1. If I switch to workspace 2, all outputs switch to workspace 2. Since the issue does not mention this behavior, but mentions i3/sway (which have no such functionality) and cross-monitor control, I just wanted to add that this should be designed/implemented in a way that is compatible with what I have.

[agjini]

Ok thanks now I understand ;-) You mention the option "Workspaces span displays".

Your absolutely right my feature request can be to add another behavior option in this setting section.

It will be so great to let the user choose the behavior.

[moosemanf]

Yes to almost all your rules. especially the immutable stuff!

As others pointed out, I would believe to "know" that my browser is on workspace 3 and my password manager at 7, is essential in being quick and using the idea of a window manager to its full extent.

Maybe I don't understand Rule 3, or I don't think it is necessarily a good idea... How would I move windows somewhere in the workspace overview then.

For me the most important fix currently would be, to not remove a workspace, just bc I closed the last window in there!

[agjini]

@moosemanf Thanks, let me clarify Rule 3.

The workspace you're currently focused on always stays alive, even when it's empty. So when you switch to an empty workspace you get the time to open an app or drag a window into it.
A workspace is only cleaned up (and removed from the panel list) once you leave it while it's still empty. Since the numbering is absolute, In reality this workspace is always reachable.

Does that address your concern? Happy to refine the wording in the issue if this version is clearer.

[moosemanf]

Hi @agjini !
To be honest, no it doesn't. I would never want a workspace to go away.

I might have a curtain project open at workspace 6 and then I close project 5 on workspace 5 and all of a sudden all other workspaces are not reachable by number just bc I closed 5 and not 6 becomes 5 and so on? that does not make any sense in the way I'm using workspaces.