Fix multi-monitor persistence and improve PaperWM dynamic workspaces support

[jtaala]

Fixes #571.

Multi-monitor workspace to monitor persistence was a bit broken (okay, quite broken).

This PR fixesworkspace-to-monitor persistence (e.g. PaperWM's ability to restore monitor-workspace layouts after a unlock or monitor change.

It also improves dynamic workspaces behaviour in PaperWM by:

• aligns some behaviours with gnome's dynamic workspace behaviour and always keep a workspace at the end;
• no longer takes into account the number of fixed worspaces when using dynamic workspaces. Previously, even when using dynamic workspaces the minimum number of workspaces was taken from the set fixed workspace's value. Now PaperWM dynamic workspace support aligns with gnome's. Of course, if you want a certain number of workspaces you can use fixed workspaces (see Gnome multitask settings).

It now also attempts to remember and restore the previous multimonitor layout across where you had a multimonitor layout, switched to single monitor (during the session) and then reconnect to multimonitors.

The previous approach used a heuristic based on some properties of the monitors - this was unstable though as monitor ordering and (indexes) can change (it's generally stable but sometimes can change).

This PR replace the heuristic (guess) with more stable monitor connector ids (e.g. "eDP-1", "HDMI-1" etc.). It does this by:

• implementing a new async dbus connector client for DisplayConfig. This gets detailed monitor spec data (like connector, e.g. "eDP-1" etc, vendor, serial, etc.);
• now upgrades Main.layoutManager.monitors by adding the connector value to each monitor (also detects monitor changes so is up to date);
• we now persist a mapping between the monitor by connector (instead of index... which is just not stable) and workspace index (this allows PaperWM to restore a workspace that had been destroyed and then recreated, e.g. if using dynamic workspaces);

If you now check the INFO_LEVEL logs on unlock (or disable/enable PaperWM, monitor changes etc.), you'll now see lines like:

Aug 13 21:23:21 jay-blade gnome-shell[1599991]: #PaperWM enabled
Aug 13 21:23:21 jay-blade gnome-shell[1599991]: Workspace 6 restored to monitor DP-1
Aug 13 21:23:21 jay-blade gnome-shell[1599991]: Workspace 2 restored to monitor eDP-1

which shows a successful restoration of persisted data.

Summary of space-to-monitor restore logic:

• new login: primary monitor gets space 1, then monitor 2 gets space 2, etc.
• lock / unlock: each monitor's last used space gets restored on unlock; - multimonitor to single-monitor: partly a gnome thing, but the space of the monitor where the mouse is will be what shows on the single monitor;
• single-monitor to multi-monitor :
  • attempt to restore the last workspace that was on each monitor.
  • if there's contention, e.g. both monitors last had the same workspace (which can happen, e.g. was on multimonitor and space 1 was on monitor 2, then monitor 2 got turned off, and then we switched space 1 to monitor 1)... then that workspace will be restored to primary monitor (primary monitor takes preference), and the next recently used workspace will go to monitor 2.

[YaLTeR]

Let me know if you get steps to reproduce this. Only thing I've seen that has ever warped pointer to the center is the switch monitor keybinds for Switch to the right monitor, Switch to the left monitor.

Updated to latest PR commit, still seeing this. Pretty much most of the time when I try to move my mouse to my second monitor, be it by moving the mouse or with the "Switch to the left monitor" bind, a splitsecond after the cursor enters the monitor it gets warped back to the center of my main monitor. I frequently need to spam "Switch to the left monitor" multiple times to finally get it over. Whenever this happens the focused window indicator in the top bar does show the second monitor window for one frame, so it is only after the pointer is on the second monitor that it is warped back.

[jtaala]

Updated to latest PR commit, still seeing this

It sounds ClickOverlay related. After a new login, how easy is it to reproduce this?

If you can always get into this state, can you try bisecting this? Especially if you're only seeing this since the last few days.

@Lythenas have you seen this?

I haven't seen this so I wonder if it's something to do with monitors with different resolutions?

[jtaala]

Give me a quick rundown of your setup @YaLTeR, so I can try replicate. Even better, if your able to take a video/photo (on phone or something) showing your setup and that issue.

• two monitors, external monitor to the left?
• external monitor resolution 1080p and laptop monitor 1440p?
• which monitor is the primary monitor?
• dynamic workspaces?
• you don't use any setting like "focus follows mouse" do you?

[jtaala]

hmm - found something that might be related. Scratch windows - in my testing if there's a scratch window on a monitor, the the switching monitor shortcuts seem to fail.

Will do some digging.

[jtaala]

Hey @YaLTeR - I think

Updated to latest PR commit, still seeing this

I think(?) I found it @YaLTeR. https://github.com/paperwm/PaperWM/pull/577/commits/1b1606f63b597a6115bc5f417f62f9fd93984e66 should fix this. Was caused by incorrect reference in Scratch to a new get function in Tiling.spaces.

Pull the latest and test that one out.

Luckily @YaLTeR uses scratch windows (purportedly) since it threw an error on console - but since I don't often use scratch windows didn't pick it up. Nice find @YaLTeR!

P.S. I'm pretty sure this was the issue but let us know @YaLTeR if it still happens!

[jtaala]

hmm - found something that might be related. Scratch windows - in my testing if there's a scratch window on a monitor, the the switching monitor shortcuts seem to fail.

Interesting, it seems scratch windows maintain focus even when moving mouse to another workspace. This differs from normal PaperWM behaviour. @YaLTeR - can you recall if you had scratch or floating windows on a monitor when the warping happened?

Will have a look at this tonight.

[YaLTeR]

Luckily @YaLTeR uses scratch windows

I do use floats occasionally, but I don't think I had any when the warping occurred.

Give me a quick rundown of your setup

Funnily enough now that I'm taking this screenshot the issue does not seem to reproduce.

dynamic workspaces?

Yep.

you don't use any setting like "focus follows mouse" do you?

I don't.

[Lythenas]

@jtaala I have occasionally seen the mouse cursor warping (also before this PR) but not recently. And it has never really been an issue. But I will try the latest changes today.

I do use the scratch layer daily. E.g. the password manager and VPN window is there. Also when running the Android Emulator I usually put it on the scratch layer because that seems to cause less trouble.

[jtaala]

Thanks @YaLTeR and @Lythenas for all the testing.

Another day another fix(es)! See latest (https://github.com/paperwm/PaperWM/pull/577/commits/638484142e168045692dd3dab564880a0c70f759) for changes which fix the scratch-windows-across-monitors issues.

I think (hope) we're nearly there with this PR.

[jtaala]

I have occasionally seen the mouse cursor warping (also before this PR) but not recently

So, I finally found that stupid pointer warp issue. Could reproduce it somewhat (basically noticed that when clicking the overview workspace thumbnail - pointer would warp to other monitor and was like "ha?").

Tracked it down to the warp monitor code being in switchWorkspace which is called whenever any workspace is activated. It was tripping on some weird corner cases.

I've now moved the warp pointer code out of there and only in switchMonitor - which means it is only ever called when using the switch monitor to left/right/etc. (which is how it should be).

P.S. is scratch / floating window was another issue... which is good because we've also fixed that.

[jtaala]

Okay, let's try this again... pretty confident that found and fixed the pointer warp code... planning on merging this into develop in a day or so (maybe saturday). Appreciate any last minute tests or feedback you have on the latest (currently https://github.com/paperwm/PaperWM/pull/577/commits/7330509886e8c415a077ec4a713f0e6289ad5a09).

Thanks all.

[jtaala]

@YaLTeR & @Lythenas,

So, there's a reason why myself and @Lythenas haven't been able to reproduce what you're seeing @YaLTeR: dynamic workspaces.

Dynamic workspaces is the issue with replug/restores. Basically, PaperWM overrides gnome's _checkWorkspaces and manages dynamic workspaces a little difrerently, and stops things like removing empty workspaces PaperWM's visible spaces.

When PaperWM is disabled we undo the PaperWM's _checkWorkspaces method. Now gnome's _checkWorkspaces is in play, and this method removes empty workspaces (since PaperWM's version isn't active).

That means that any change in monitors will trigger gnome's version and remove empty workspaces etc. Problem is PaperWM treats workspaces differently, and hence on restore, workspaces have been removed, are different then when PaperWM left... and it's now left with a bit of a mess trying to restore spaces (which are intrinsically linked to workspaces) against a changed gnome workspace landscape (without know what happened).

Anyways, not sure what to do here. I'll look at restoring empty workspaces to what PaperWM saw when unlocking before dynamic workspaces changed things (without PaperWM's knowledge).

So basically, this PR fixes a ton of issues with multimonitor in PaperWM and are good changes... for fixed worksapces... but dynamic workspaces presents a few extra challenges here.

[jtaala]

As I feared, dynamic workspaces leads to some very indeterminate behaviour during restore. Weird stuff that doesn't happen with fixed workspaces. Easily reproducible bugs when an external monitor is "yanked" out, or turns off / timeouts during a lock state. Even in lock, gnome code will then remove/modify workspaces and leave PaperWM in a state where it can't restore correctly. This is essentially why @YaLTeR was seeing workspace switching and other issues, when I wasn't.

Furthermore, I've found some pretty weird bugs around using dynamic workspace functions (like shortcuts to create a dynamic workspace, and dragging a window in overview to create an "in-between" workspace. It quickly messes up the workspace names/ordering etc. and leads to some other weird behaviour.

I don't see a way around this, other than rewriting dynamic workspace support in PaperWM - which will likely require quite some refactoring and redesign on the spaces, monitor code. This would provide a good opportunity to do a better approach for dynamic workspaces.

Hence, in order to provide a stable experience (e.g. workspaces/monitors restore properly etc.) we pretty much need to make dynamic-workspaces a controlled setting in PaperWM (like other settings that don't work well in PaperWM, e.g. attach-modal-dialogs, edge-tiling, workspaces-on-on-primary).

This means that PaperWM will now disable dynamic workspaces when it is enabled - and restore the original setting when PaperWM is disabled.

Sadly, currently you can't have both consistent and stable restores AND dynamic workspaces. There's too many corner cases and issues currently with PaperWM and dynamic workspaces.

@YaLTeR, best way forward I can see is doing this, and then working on proper/better dynamic workspace support - as you outlined previously.

[YaLTeR]

I see, understandable.

This means that PaperWM will now disable dynamic workspaces when it is enabled - and restore the original setting when PaperWM is disabled.

Could it let you enable it with a warning or something? Because it works "well enough" at least for what I'm doing; I can deal with the occasional workspace moving around, and know to avoid the overview workspace thumbnails with Paper by now.

[jtaala]

Could it let you enable it with a warning or something?

Yeah, I can add a persistent user config setting (prob will call it something like allow-dynamic-workspaces that you can set to true in dconf etc.).

[smichel17]

What about, as a workaround, a way to move a workspace to a different monitor? Or swap two workspaces between monitors. So for now we don't worry about whether we sometimes get mixed up and put the wrong workspaces on the wrong monitors, because the user can fairly easily get them back where they belong. Maybe a shortcut, with no default keybinding.

(note: I haven't read the whole thread. I'll test this out next week)

[jtaala]

What about, as a workaround, a way to move a workspace to a different monitor? Or swap two workspaces between monitors. So for now we don't worry about whether we sometimes get mixed up and put the wrong workspaces on the wrong monitors, because the user can fairly easily get them back where they belong. Maybe a shortcut, with no default keybinding.

Well, this would help but not workaround all the issues. With dynamic workspaces, you not only have workspaces being incorrectly restored - you also have instances where windows of workspaces are incorrectly restored to the wrong workspace (e.g. windows were on workspace 3 but on restore they all get restored to workspace 2).

Plus, it wouldn't help with the workspace names & paperwm space settings getting impacted/messed up for dynamic workspaces.

In other words there's deeper issues, other than just workspaces being restore to an incorrect monitor.

[jtaala]

a way to move a workspace to a different monitor? Or swap two workspaces between monitors.

But I do think this is a good idea and will be super useful (currently to swap spaces on monitors I need to stack switch a space away, then move to the other monitor, and stack switch that space to on the monitor, then do the same on the original monitor). A quick shortcut to do that would be very useful.

[jtaala]

@YaLTeR Just added a setting to stop PaperWM controlling dynamic-workspaces. Run this from a terminal window (once you pull latest on this PR and logout/login):

dconf write /org/gnome/shell/extensions/paperwm/allow-dynamic-workspaces true

then PaperWM won't touch dynamic workspace settings.

Note: once you run that you can disable/enable PaperWM (which will restore dynamic workspace and then when PaperWM is enabled again won't touch it).

[jtaala]

Ha... that was unexpected.

I had an idea to use our space.uuid (each space has a unique id we use for saving settings etc.) for restore instead of the workspace index... theory being that with dynamic workspaces the workspace index is not stable.

Turns out - I'm now getting a stable restore with dynamic workspaces...

As such, I've now disabled the enforcement of fixed workspaces - as it may not be needed now.

I'll continue to test the latest out - @YaLTeR, if you can also start testing this one out, would be appreciated.

Might still be some corner cases since I've just implemented this but it looks promising.

[jtaala]

All, please see latest changes here. Namely this:

It also improves dynamic workspaces behaviour in PaperWM by:

• aligns some behaviours with gnome's dynamic workspace behaviour and always keep a workspace at the end;
• no longer takes into account the number of fixed worspaces when using dynamic workspaces. Previously, even when using dynamic workspaces the minimum number of workspaces was taken from the set fixed workspace's value. Now PaperWM dynamic workspace support aligns with gnome's. Of course, if you want a certain number of workspaces you can use fixed workspaces (see Gnome multitask settings).

Dynamic workspaces seems to be performing well with latest changes and restoring stably (that's a word right?). I'm quite liking it. It's seems intuitive and allows to create workspaces when needed, and destroys the end ones when empty.

A couple of things to note now:

• in overview, dragging a window to workspace thumbnails to create an "in-between" workspace works fine... but note that the workspace is injected / moved (this is gnome behaviour). e.g.
  • dragging a window in between workspace 1 and 2, will move workspace 2 (and windows) to workspace 3 and inject the moved window to "workspace 2";
  • this makes sense from a technical pov but might be surprising to users (unless they're used to this behaviour in dynamic workspaces);
• there is a use-case that can restore unstably:
  • when you lock and then "yank" out the external monitor cable (which is a destructive monitor change) AND then unlock and eventually reconnect;
  • note that this differs from the external monitor turning off or sleeping - which restores fine;
  • not quite sure what to do here, it's a pretty "destructive" use case but can happen.

[YaLTeR]

Thanks! I'm going to give this a try. Sounds great!

unless they're used to this behaviour in dynamic workspaces

Yeah, this is what I expect (I don't even look at workspace numbers tbh)

[YaLTeR]

So after rebooting some of my autostarted windows are glitched out, and there's also this in the journal:

авг 21 08:22:03 gnome-shell[1488]: JS ERROR: Exception in callback for signal: showing: TypeError: Tiling.spaces.monitors is undefined
                                      fixTopBar@/var/home/yalter/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/topbar.js:709:17
                                      _callHandlers@resource:///org/gnome/gjs/modules/core/_signals.js:130:42
                                      _emit@resource:///org/gnome/gjs/modules/core/_signals.js:119:10
                                      _changeShownState@resource:///org/gnome/shell/ui/overview.js:300:14
                                      runStartupAnimation@resource:///org/gnome/shell/ui/overview.js:683:14
                                      _startupAnimationSession@resource:///org/gnome/shell/ui/layout.js:778:27
                                      _startupAnimation@resource:///org/gnome/shell/ui/layout.js:763:18
                                      _prepareStartupAnimation@resource:///org/gnome/shell/ui/layout.js:754:14
                                      async*_loadBackground/signalId</id<@resource:///org/gnome/shell/ui/layout.js:681:26

[jtaala]

So after rebooting some of my autostarted windows are glitched out, and there's also this in the journal:

авг 21 08:22:03 gnome-shell[1488]: JS ERROR: Exception in callback for signal: showing: TypeError: Tiling.spaces.monitors is undefined
                                      fixTopBar@/var/home/yalter/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/topbar.js:709:17
                                      _callHandlers@resource:///org/gnome/gjs/modules/core/_signals.js:130:42
                                      _emit@resource:///org/gnome/gjs/modules/core/_signals.js:119:10
                                      _changeShownState@resource:///org/gnome/shell/ui/overview.js:300:14
                                      runStartupAnimation@resource:///org/gnome/shell/ui/overview.js:683:14
                                      _startupAnimationSession@resource:///org/gnome/shell/ui/layout.js:778:27
                                      _startupAnimation@resource:///org/gnome/shell/ui/layout.js:763:18
                                      _prepareStartupAnimation@resource:///org/gnome/shell/ui/layout.js:754:14
                                      async*_loadBackground/signalId</id<@resource:///org/gnome/shell/ui/layout.js:681:26

Ewww - does that happen every start?

[jtaala]

autostarted windows

Hmmm autostarted windows! What are they and how are you autostarting them? Weirdly, they seem to start before PaperWM has finished initing monitors etc.

This the first time you've noticed it?

[YaLTeR]

Hmmm autostarted windows! What are they and how are you autostarting them? Weirdly, they seem to start before PaperWM has finished initing monitors etc.

~/.config/autostart, also available from GNOME Tweaks

This the first time you've noticed it?

Yeah, it's the first time it happened. Restarting the extension fixed it fwiw

[jtaala]

Yeah, it's the first time it happened. Restarting the extension fixed it fwiw

Cool, it's worth putting an optional chain on it anyways.

Apart from that - is dynamic workspaces working somewhat now?

[YaLTeR]

Apart from that - is dynamic workspaces working somewhat now?

Still giving it a go, seems to work so far. Some very minor things:

• on an empty monitor there should be only one workspace I think, right now there are two empty ones
• I seem to have quite a few workspaces named "Workspace 11"

[jtaala]

• I seem to have quite a few workspaces named "Workspace 11"

Yeah, that's prob from your previous use of dynamic workspaces - which wasn't handled as nicely, and had some funny stuff going on (from old restore etc.)

Disable PaperWM, open up dconf, find paperwm folder (just search), right-click on workspaces folder (under paperwm) and select reset recursively and the apply.

Then enable PaperWM again.

There will be a terminal command to reset workspaces that we should prob document.

[jtaala]

• on an empty monitor

Hmm - you're prob on multimonitors? So you have one extra (always have an extra).

E.g. 1 space for built-in monitor, 1 space for external monitor and once at the end.

Consistent with single monitor setup (e.g. 1 for monitor and one at end).

[YaLTeR]

Ah, so like the empty workspace is still "shared" between monitors?

[jtaala]

Ah, so like the empty workspace is still "shared" between monitors?

Yes. In PaperWM ALL workspaces (not shown on current monitor/s) are shared between any monitor.

E.g. if you're on wayland and touchpad, do a 3-finger swipe down and you should see other spaces. Can do that on either monitor (and see the same spaces).

[YaLTeR]

Right, I keep forgetting that

[YaLTeR]

I'm right now on 3903938e041d46bbbfceae33c2ea0fd203198e73 after a resume from sleep with my two monitors, and there's no empty workspace at the bottom of the main monitor. I have 4 workspaces in total with the only empty workspace sitting on the second monitor. What I did to get this was to Super+` the non-empty workspace from the second monitor into the main monitor.

This is the same as PaperWM used to work before, but not sure if intended with the latest changes.

[jtaala]

This is the same as PaperWM used to work before, but not sure if intended with the latest changes.

Hey Ivan, yes this is intended.

You seem to be struggling with workspace concepts in PaperWM - it is different from other window managers but probably one of my favourite things about PaperWM.

So, there's no such thing as a workspaces "belonging" to a monitor - there's simply a single "line" of workspaces available to any monitor, and we simply "show" a workspace on a monitor - but once it's moved away from any monitor - it can be "shown" on another monitor.

Hence

and there's no empty workspace at the bottom of the main monitor

doesn't make any sense in PaperWM, since no workspace can be "at the bottom" of a monitor. Once it's not shown on a monitor, it's back in the "line" or available workspaces (which are available to any monitor).

What I did to get this was to Super+` the non-empty workspace from the second monitor into the main monitor.

This is exactly the function of Super+backtick - it shows the last used workspace on any monitor - and this allows us to quickly move a workspace to another monitor (which is another one of my favourite features) - e.g. "unshow" (basically switch to another workspace on monitor 1) and then on another monitor hit Super+backtick and you've just "moved" a that workspace to another monitor.

[YaLTeR]

You seem to be struggling with workspace concepts in PaperWM

Nah, I'm just never sure how close "improved dynamic workspaces support" got to how dynamic workspaces work in GNOME :) It's okay though

it is different from other window managers

Not really, i3 and sway also work this way, seems to be quite a popular implementation actually. Funnily enough when I used sway for a few years, I set up a static set of workspaces for each monitor, because even then I found it more convenient to have per-monitor workspaces.

[jtaala]

Nah, I'm just never sure how close "improved dynamic workspaces support" got to how dynamic workspaces work in GNOME :) It's okay though

Gotcha. Improved support basically means PaperWM isn't (or shouldn't) be borking workspace names when using standard dynamic workspace features (like dragging windows to overview thumbnails to create a new workspace in between other workspaces) and other issues which caused a bunch of duplicate workspace names etc. and always keeping an empty workspace for use at the end.

Not really, i3 and sway also work this way.

Yes, I also come from i3, so this seemed very natural to me - I assumed from many of your references about workspaces and monitors (e.g. "Right, I keep forgetting that") that it may have been a foreign concept - but good to hear it's not!

[jtaala]

I'm just never sure how close "improved dynamic workspaces support" got to how dynamic workspaces work in GNOME :)

Fair enough - for what it's worth, I agree that many gnome approaches (for dynamic workspaces or otherwise) isn't what I consider best - but given PaperWM is a gnome extension, "improved dynamic workspaces support" means improved support for (gnome's) dynamic workspaces.

[jtaala]

After using this with dynamic workspaces for a few days now, I think it really needs a shortcut to inject/insert a new workspace to the right of the current workspace (basically do what happens when you drag a window in overview between two of the workspace thumbnails in overview).

[jtaala]

Merging into develop to get this more widely tested.