Switch to a workspace sticked to another monitor

[inwaar]

Is your feature request related to a problem? Please describe. I have 2 monitors setup and somehow all workspaces are moved to my right monitor. And there are no workspaces on the left monitor at all. Is there a way to move (not swap) workspaces from one monitor to another?

Describe the solution you'd like Have a shortcut to move a workspace to a specific monitor. Or make optional sticking a workspace to a monitor.

It is also interesting in what way the workspaces distributed between monitors by default (say if I have 5 workspaces and 2 monitors)? I see that when a workspace has no windows I can switch to it from any monitor but once there is at least one window in a workspace the workspace sticks to one specific monitor, is this expected behavior? Would it possible to make this optional maybe?

[jtaala]

I have 2 monitors setup and somehow all workspaces are moved to my right monitor. And there are no workspaces on the left monitor at all.

Hmm I might not be understanding this but a workspace should be on each monitor. Can you put up some screenshots or video to show this? Or do you mean in gnome overview?

You can move workspaces to other monitors but you need to swap them (as a workspace needs to be on each monitor) - see swap monitor keybinds

But I'm guessing that might not be what you mean?

[Lythenas]

What you describe is indeed the behavior of Super+PageUp/Down. I don't remember why it is this way.

But using Super+AboveTab you can still switch to any workspace that is not currently shown.

[inwaar]

I have 2 monitors setup and somehow all workspaces are moved to my right monitor. And there are no workspaces on the left monitor at all.

Hmm I might not be understanding this but a workspace should be on each monitor. Can you put up some screenshots or video to show this? Or do you mean in gnome overview?

It is easy to reproduce: 1) Setup say 4 fixed workspaces 2) Open a text editor (or any window) on monitor 1 on workspace 1 3) Switch workspace on monitor 1 to workspace 3 (with Super-PgDn) 4) On monitor 2 try to iterate workspaces with Super-PgUp/Super-PgDn 5) See no workspace 1 in the list on the monitor 2

You can move workspaces to other monitors but you need to swap them (as a workspace needs to be on each monitor) - see swap monitor keybinds

But I'm guessing that might not be what you mean?

Yes, swapping is working, but if most of the workspaces are "sticked" to one monitor and only 1 workspace to another monitor - this swapping is not really something usefull. In this case what can help is to close all windows on some workspaces which will "unstick" when from specific monitors.

[inwaar]

What you describe is indeed the behavior of Super+PageUp/Down. I don't remember why it is this way.

But using Super+AboveTab you can still switch to any workspace that is not currently shown.

Thanks, @Lythenas Super+AboveTab works. Is this possible to make it also work for Super+PageUp/Down or make it configurable?

[Lythenas]

I think that would make sense, but we need to think a bit about how to order the workspaces conveniently. E.g. put the workspaces of other monitors after what is currently shown. And maybe mark them somehow.

We could maybe also put this as a new keybinding that is unbound by default, that you can then bind Super+PageUp/Down to.

I think we should avoid changing the behavior of the default (and probably often used) keybindings.

[jtaala]

Hey @inwaar,

This is a common misconception in PaperWM. Apart from the workspaces shown on the monitors - all other workspaces are actually in a stack that is available to any of the other monitors.

The swapping is just a shortcut for workspace stack switching. I.e. it's just doing this very fast:

https://github.com/paperwm/PaperWM/issues/571#issuecomment-1671623560

You see how I was three-finger swiping down on the video? You can keep swiping down to get any of the other workspaces any of your monitors.

[jtaala]

Thanks, @Lythenas Super+AboveTab works. Is this possible to make it also work for Super+PageUp/Down or make it configurable?

Ah, I understand now. Yes, that's a bit of a bug. It really should be in there.

[jtaala]

but we need to think a bit about how to order the workspaces conveniently. E.g. put the workspaces of other monitors after what is currently shown. And maybe mark them somehow.

No, it's really just a bug - in @inwaar's example, it should show workspace 1 on monitor two - with workspaces in workspace order.

[Lythenas]

No, it's really just a bug - in @inwaar's example, it should show workspace 1 on monitor two - with workspaces in workspace order.

I'm not actually sure what "workspace above/below" is supposed to mean. Super+AboveTab switches in the order they were last used. But "above" and "below" imply some other ordering. I guess currently it is all workspaces on the current monitor in numeric order. This is probably useful to keep that way. I expect people would rely on that and get annoyed if workspaces from the other monitor were mixed into that.

[jtaala]

I'm not actually sure what "workspace above/below" is supposed to mean. Super+AboveTab switches in the order they were last used. But "above" and "below" imply some other ordering.

Well, it just means in sequential order, e.g. Workspace 1 --> Workspace 2 --> etc., i.e. workspace is "above" workspace 2 (remember paperwm's concept of "spaces" are conceptually vertically stacked).

I guess currently it is all workspaces on the current monitor in numeric order. This is probably useful to keep that way. I expect people would rely on that and get annoyed if workspaces from the other monitor were mixed into that.

I'm not sure what you mean by:

I expect people would rely on that and get annoyed if workspaces from the other monitor were mixed into that.

See comment below (they actually are already mixed in)... that is, PaperWM keeps a workspace stack (not bound to any monitor). There's two sets of methods in tiling.js: selectSequenceSpace (i.e. numerically sequenced workspaces) and selectStackSpace which uses mru (most recent used) ordering... but they're essentially doing the same thing... although ordering workspaces differently.

This is a common misconception in PaperWM. Apart from the workspaces shown on the monitors - all other workspaces are actually in a stack that is available to any of the other monitors.

[jtaala]

Noting the issue where the workspace in sequence switching isn't showing - although it will show if you "stack" switch first... and then sequence switch.

[jtaala]

Anyways, it's a trivial fix if you want to try/test it out.

@Lythenas, @inwaar, happy to create a branch if you want to test it out.

@inwaar - are you on Gnome 44 or Gnome 45?

[jtaala]

The fix will just be changing this line:

https://github.com/paperwm/PaperWM/blob/82db457541a7138c9ad5f4984f871d370f89810f/tiling.js#L2255

to this:

          (this.monitors.get(space.monitor) !== space))

(note that is from the Gnome 45 branch).

[jtaala]

I guess currently it is all workspaces on the current monitor in numeric order

Not quite - it's more like (example with two monitors, monitor 1 & monitor 2, and sequence switching on monitor 2):

"all spaces available, except for the space currently shown on monitor 1.... oh, and also NOT the last space that you just sequence switched from on monitor 1.... that is until you stack-switch to that space on monitor 2... then it will appear on monitor 2 in sequence switching "...

Note: it's currently a little more complicated than the above - as behaviour depends on which space you last switching from on monitor 1... and what's space is currently on monitor 2. But it should just be:

"all spaces available, except the one currently shown on monitor 1".

[jtaala]

When it really should be:

"all spaces available, except the one currently shown on monitor 1".

[Lythenas]

To be honest I don't even use many workspaces at once, usually at most three over two monitors. So I don't really know if people are actually relying on the current behavior.

But if I understand correctly this should be the correct behavior:

• Monitor 1: WS4, Monitor 2: WS3
• switch one workspace up on monitor 1: from ws4 to ws2
• switch one workspace up on monitor 2: from ws3 to ws 1
• Now monitor 1: WS2, monitor 2: WS1
• and then do the reverse direction, switch one workspace down on monitor 1: ws2 to ws3
• switch one workspace down on monitor 2: ws1 to ws2
• Now monitor 1: WS3, monitor 2: WS 2

On the current behavior you would end up on the same situation as you started, right?

[Lythenas]

"all spaces available, except for the space currently shown on monitor 1.... oh, and also NOT the last space that you just sequence switched from on monitor 1.... that is until you stack-switch to that space on monitor 2... then it will appear on monitor 2 in sequence switching "...

Note: it's currently a little more complicated than the above - as behaviour depends on which space you last switching from on monitor 1... and what's space is currently on monitor 2. But it should just be:

If I have 4 workspaces on monitor 1 and one workspace on monitor 2, on monitor 2 I can switch to none of the 4 workspaces from monitor 1. So I don't think your description is really accurate.

[Lythenas]

In any case I'm mostly indifferent to changing this behavior, I think both (the current and what you described) make sense. That's why I proposed to add a second set of keybindings. Then the user can choose which behavior they like.

[jtaala]

If I have 4 workspaces on monitor 1 and one workspace on monitor 2, on monitor 2 I can switch to none of the 4 workspaces from monitor 1. So I don't think your description is really accurate.

Yes, note this:

Note: it's currently a little more complicated than the above - as behaviour depends on which space you last switching from on monitor 1... and what's space is currently on monitor 2. But it should just be:

Try just replicate what @inwaar was saying. e.g.

1. 4 workspaces
2. workspace 1 on monitor 1 and workspace 2 on monitor 2
3. monitor 1: switch to workspace 3
4. move mouse to monitor 2 - you can switch to workspaces 3 and 4;
5. stack switch to workspace 1 on monitor 2;
6. now try sequence switch on monitor 2... workspace is now available to sequence switch

[jtaala]

I'll put up a video of what I mean

[jtaala]

Hey @Lythenas,

Here's the a link to a video on this:

https://www.youtube.com/watch?v=JLJWB-s5Z_0

[Lythenas]

Sorry I wasn't precise enough, what I meant with 4 workspaces on monitor 1 is "4 workspaces with a window". None of the workspaces with a window show up when trying to switch to them on monitor 2. So it is not just the last workspace you switched from on monitor 1, it is all workspaces with a window that were originally opened on workspace 1.

After a quick look at the code it does what I meant: It shows all workspaces that were either 1) previously assigned to the current monitor (space.monitor === monitor) or 2) are empty (space.length === 0) and not currently assigned to a monitor (this.monitors.get(space.monitor) !== space).

Looking at the code, to me this looks like it was intended this way.

But in any case I would be fine with changing that behavior. I was just concerned that users are used to the current behavior and will get confused when we change it.

[jtaala]

Ah, gotcha! I understand now. Yes, most likely that was how it was originally written. I just thought the behaviour was strange, but given what you mentioned - I guess it makes sense. And from that I can see why people assume in PaperWM that there's a hard structuring of workspaces to monitors! (which is fair enough, but I love that you can have any space on any monitor).

Once you stack-switch to one of those spaces, it then becomes available (i.e. space's monitor is now set to the monitor changed to).

Apologies there for the confusion. Yeah, given this, we could either add an option or keybind (although I'm not sure what we'd call the option, or the keybind).

[jtaala]

This older PR makes a bit more sense now https://github.com/paperwm/PaperWM/pull/361

How about something like (two options):

• "Isolate spaces to monitors (ordered space switching)"
• "Isolate spaces to monitors (most recent space switching)"

That way, users can choose their preferred beahaviour for both sequence (ordered) or most-recent. We'd keep the current behaviour as default.

Using the above, users can then choose if they want workspaces to be more strictly "assigned" to monitors.

Thoughts?

[Lythenas]

Seems fine, but it is missing the option for "don't isolate spaces to monitor", right?

[jtaala]

Well, don't isolate spaces to monitor would be

Isolate spaces to monitors (ordered space switching) = false
Isolate spaces to monitors (most recent space switching = false

I don't know though - maybe it's easier just to add a couple more keybinds, e.g.

Switch to workspace above (show from all monitors) Switch to workspace below (show from all monitors)

(or something). Btw, if you wanted to change that above/below nomenclature, now's prob the time to do it.

[jtaala]

if went with the keybind option, could leave blank by default or use something like Super+Shift+PageUP/PageDown.

[Lythenas]

I think having that as separate keybindings would be better and we can leave them blank by default. E.g.

• Switch to workspace above/below (current monitor)
• Switch to workspace above/below (all monitors)

And I think we probably don't need "Isolate spaces to monitors (most recent space switching)".

And we should probably have a section in the readme to properly explain all this^^

[jtaala]

Sounds good.

Def need a section re this.

Are you able to take this one and do up a PR?

And we should probably have a section in the readme to properly explain all this^^

[jtaala]

P.S. if you're on gnome 44 - feel free to do the PR to merge into gnome-44 branch and I can then merge into gnome-45.

[Lythenas]

I can definitively make a PR this week.

Also I updated to Gnome 45 yesterday, so now I'm on Gnome 45 on one machine and Gnome 42 on the other. I will try to do a PR for both, but I will start with only one.

[inwaar]

Hi, thanks for adding this. Is this feature available on a specific version/branch? Unfortunately can't find it in the shortcuts yet

[jtaala]

Hey @inwaar - it's currently only on Gnome 45. You could reach out to @Lythenas about porting it to gnome 44.

[Lythenas]

Ah yes, I wanted to do that. I will look at it today.