Multitasking View displays incorrectly with 2 displays of varying resolutions or aspect ratio

[sdnkr]

What Happened?

Multitasking View doesn't display correctly on a setup with monitors of varying resolutions or varying aspect ratio. On the picture we can see that smaller screen displays on top of main screen.

Multitasking View

Main monitor: 27" 1920x1080
Secondary monitor: 19" 1280x1024

Display Settings

Steps to Reproduce

1. Connect monitors with varying resolutions and aspect ratio (1920x1080, 1280x1024).
2. Run Multitasking View

Expected Behavior

Should display separate multitasking view on every monitor I guess.

OS Version

7.x (Horus)

Software Version

Latest release (I have run all updates)

Log Output

No response

Hardware Info

No response

[davidmhewitt]

This may be resolved by #1640.

I don't have monitors with differing aspect ratios, but I do have monitors with different resolutions, and MultitaskingView is working okay with the fix I've written in #1640.

I'd hope this will make it into the next update for Gala.

[sdnkr]

I can verify this fix when it's released.

For the time being I have found a setting that makes this view ignore other monitor and just shows windows from primary display.

gsettings set org.gnome.mutter workspaces-only-on-primary false

The key name is odd. Was there ever an option to have distinct workspace for other displays?

[davidmhewitt]

Yes, I believe setting that means that you get individual workspaces for each display. But they all switch at once when you switch workspaces.

The Multitasking view code has always historically been written in such a way that it ignores other displays while that is set to false. I don't think it's a setting we expose in the UI, so it's not an officially supported configuration.

But it would possibly make more sense to draw a full multitasking view per display with the workspace switcher at the bottom of each display so you could visibly see what applications were running on which workspaces per-display. But, I think there's quite a bit of complexity in doing that, which is probably why it was never implemented for an unsupported setting 😉

[davidmhewitt]

I'm going to close this issue as a duplicate of #1519 as it's the same root cause and has been confirmed fixed by #1640.