Conversation
How to contributeInstallationImportant to know :If you have installed material shell please remove it first, since the make install just makes it installed for the next login session (wayland). So you log out login and after log out it will default back to the previous installed version which could lead to confusions / false issues so please acknowledge this If you stumble upon a bug please create an issue and we will link it here. List of existing Issues
6 . (wayland) when sub window spawns it sometimes moves the parent window also to the other monitor, resulting in wrong click translation and leaving a gab on the monitor it previously was on, but the title bar of that monitor still contains that item but the window is now on the wrong monitor and is most of the times either half visible, half clickable or complete garbage. (ms believes it is still on that screen, so using up the screen space and showing the window as item in the window list but without the window being still present on the monitor usually the bug is less heavy and just result in a broken window and workspace on where the gap.
Solved issues so far:
|
|
You need to install the git version of the extension and then switch to the PR branch and |
|
For the monitor scaling issue: |
|
Did you applied the code changes by pulling and reinstall? |
|
In order to apply lastest changes from the checkout branch you have to: For the flashing window does it happen when you open app from Material Shell launcher or from external sources like keyboard shortcut? |
|
I pushed some changes that should help regarding the flickering issue and the hidden apps |
Screencast.from.2023-03-01.09-12-25.webmthe decision where to spawn the new window , on which monitor i didnt moved the window.. |
| global.display.get_monitor_scale(monitorIndex) | ||
| ); | ||
| getPanelSize() { | ||
| return this.getScaledSize(this.themeSettings.get_int('panel-size')); |
There was a problem hiding this comment.
Why does this no longer depend on the monitor index? You can have different dpi scaling on different monitors, can you not?
There was a problem hiding this comment.
On X11 you cannot and on Wayland it does work properly only if you have fractionnal scaling enabled by gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" and with this setting enabled the UI scaling factor is set to 1 and the scaling is automatically managed by Clutter
| msWindow.lifecycleState.type === 'app-placeholder' && | ||
| msWindow.lifecycleState.waitingForAppSince !== undefined | ||
| ) { | ||
| // If there is an authentication dialog postpone the window cleaning process |
There was a problem hiding this comment.
Why do we have to do this?
There was a problem hiding this comment.
When you try to open an app that require sudo there is an system authentication dialog that ask for the sudo password.
Our routine detect this has app didn't opened properly and close the MsWindow before the app could be opened which lead to actualizing the focus on another tileable stealing the focus from the authentication dialog
| * On creation window can jump from monitor to monitor quickly for obscure reason until they stabilize on the correct one | ||
| * In order to get ride of the visual glitch of this behavior we guard rapid changes | ||
| */ | ||
| setWindowToMsWorkspaceWithCreationChaosProtection( |
There was a problem hiding this comment.
Ugh, this is ugly, bug I suppose
There was a problem hiding this comment.
Some gnome apps like the gnome terminal does jump around monitor on their creation causing tiling flickering I didn't found a better way to handle this
|
When opening a new app on a workspace with multiple tabs already, the whole workspace animates quickly by sliding to the left. This is kinda jarring and not an improvement imo. |
This is a new behavior caused by this PR? |
Ah, nvm. It's not caused by this PR. |
|
I tested it locally, and I cannot spot any obvious bugs. |
|
Hellllo :) As this work is happening I'd like to add that I have another bug here. I can't get Workspaces to work on the second monitor. When I activate the option in gnome shell options, it reverts to workspaces on primary. Thank you for working on this ! It'll make everything so much nicer <3 |
We can't assume users will enable this. It should not break by default. |
would something like this work? i currently cant debug |
|
We can't force enable as Gnome can't enable this option by default because it come with severe downside too (XWayland window become blurry). The best thing we can do is to invite them to do it but we don't have a proper place to do that. We should have a specific page to warn users about stuff like incompatible extensions, warning about settings override and stuff but we currently don't. I'll still merge this as it's full of improvements with no down-side |
|
@Xqua Sorry for the answer delay ! You are right we are currently incompatible with |




Effort in making multi-monitor work better:
First ensure to have a first class support of the following configuration:
Gnome settings
Material Shell settings
Using those settings and the code changes from this branch let's list all unexpected behavior and we will expand from there.