Wayland: Context menus and menu bar drop-down menus open in the center of the screen

[vmsh0]

Describe the bug When opening a menu from the top menu-bar, the menu appears in the center of the screen.

To Reproduce Steps to reproduce the behavior:

1. Click on e.g. 'File'

Expected behavior The menu should open just below the corresponding menu-bar item, i.e. the File menu should open right at the top-left of the screen, the Edit menu just slightly right of that, etc.

Screenshots

Platform information

• Arch Linux
• Linux enhorning 6.0.11-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 02 Dec 2022 17:25:31 +0000 x86_64 GNU/Linux
• Sway (sway 1:1.7-10)

Additional context This is probably because I'm using a tiling window manager, which spawns floating windows in the center of the screen.

When I open a menu item, I see the following message in the log:

18:18:28.220 | WARN  | main_thread | Qt         | QQmlComponent: Created graphical object was not placed in the graphics scene.

which seems to boil down to here.

I spent a couple hours hacking with your QML scripts, but due to my complete ignorance about Qt I haven't concluded that much. Interestingly, by means of printf-debugging, I have traced the aforementioned warning message from Qt to this QML function in your framework. That is, instrumenting that function to:

        function loadMenu() {
        console.error("xxx 1")
            loader.active = true
        console.error("xxx 2")
        }

produced the following console output:

18:18:28.212 | ERROR | main_thread | Qt         | loadMenu: xxx 1
18:18:28.220 | WARN  | main_thread | Qt         | QQmlComponent: Created graphical object was not placed in the graphics scene.
18:18:28.221 | ERROR | main_thread | Qt         | loadMenu: xxx 2

I pretty much stopped my investigation here as I don't get how the loader.active = true line can have the side effect of printing that other message in the same thread (again, I'm basically completely ignorant about Qt).

[rzvncj]

FWIW it's not an Arch Linux thing. I'm using MuseScore on Arch Linux as we speak and all menus are where they are supposed to be. But, I'm using it with Gnome.

[LGFae]

I am currently having the same problem. Also on Arch, but I am using river as a window manager, which is also tiling.

[vmsh0]

I am currently having the same problem. Also on Arch, but I am using river as a window manager, which is also tiling.

Ooops. Looks like you opened the bug while I was investigating the issue, and I didn't bother re-checking for duplicated before posting. Interesting race condition :P

[vmsh0]

Some additional information: Sway has an IPC socket that can be accessed e.g. through the swaymsg command. This is the output of swaymsg -t subscribe -m '["window"]' after clicking on a menu-bar item (e.g. File"): https://paste.sr.ht/~vmsh0/91599474a7cf3f4b6e8c869629013da42ab7e43c

What I see there: the window for the menu is created, and then it is rendered floating.

So my guess is that MuseScore sets the window of the window during creation, or anyway before turning it to floating.

The issue with that logic is that application-provided position information has no meaning for a non-floating window in a tiling window manager, so the window manager probably either just discards it altogether, or at least it ignores it during the non-floating -> floating transformation (instead just putting the window at the center of the screen).

My guess is that the solution would be one of:

• creating the window as a floating window directly
• setting the position after making the window floating

EDIT: I tried to hack src/framework/uicomponents/view/popupview.cpp a bit, e.g. explicitly calling m_window->setPosition() after the show() (even asynchronously) to no avail. When the call is performed, the window manager doesn't even emit an event. Also, it seems like the aforementioned sequence of events (create window, set to floating) might be implemented in Qt as opposed to MuseScore, so maybe this is a Qt bug? Specifically, it might have to do with that failure to set the window parent. Afaik, absolute positioning in Wayland is a no-no, so the floating window not having a parent might be the entire reason why positioning information is ignored, as opposed to my order-of-operation hypothesis.

[LGFae]

No, I believe the problem is that the way the window is being created is "wrong". I think what's happening is that musescore4 is asking for a whole new OSwindow, instead of manually making a pop-up window. This is because stuff like browsers and musescore3 all work correctly despite me being in a tiling WM.

EDIT: sorry, hadn't read your entire comment yet. Wayland allows for popups using the XDG shell. This is actually another reason why I believe the problem is how the window is being created. My guess is they aren't making the "correct" call with xdg_popup and are instead just creating a new, fully fledged OSwindow. Whether this is a musescore4 problem or a qt problem is beyond me, but since other qt applications seem to work fine, I'd put my bets on it being musescore4.

[ntninja]

I’m curious what the rationale was to actually implement your own menu bar using QML ListView instead of the QML MenuBar? After a quick review, all I could find was this commit where this new behaviour was introduced for no apparent reason. Because, to be honest, this issue looks the exact kind of thing one would mess up due to unnecessarily reimplementing things instead of using what’s already there, but hopefully I’m just missing something important here.

A annoying side-effect of this decision is that MuseScore does not integrate with the global menu on KDE – an issue macOS received a painful-looking workaround for so it wouldn’t suffer the same fate, and this makes make all the more curious why that was seen as preferable by Musescore’s developers over just using QML MenuBar. (And it couldn’t have been a version incompatibility since the entirety of Musescore 4.0’s development targeted Qt 5.15 only and the QML MenuBar was introduced back in Qt 5.10.)

[cbjeukendrup]

QML menus and popups can only live inside the main window; they can't exceed its borders. This is because they are no real menus in a real popup window, but they are not more than graphical drawings inside the main window. But for us, it is crucial that popups are not bounded to the main window, in many cases. Therefore we were forced to build a custom solution.

QML MenuBar (from QtQuick.Controls) is also just a graphical drawing inside a window, so it wouldn't fix any integration with the system's native menubar. What might work is the MenuBar from Qt.labs (https://doc.qt.io/qt-6/qml-qt-labs-platform-menubar.html). But most probably that will only work on some Linux distros with some window managers, if any at all, so we can't fully switch to it on Linux.

The creation of the popup/menu window is still managed via Qt, so we don't have much control about how the native window is created exactly. There is a chance that you can fix this by playing with the so-called window flags of the QWindow.

[vmsh0]

The creation of the popup/menu window is still managed via Qt, so we don't have much control about how the native window is created exactly. There is a chance that you can fix this by playing with the so-called window flags of the QWindow.

Yeah, this is what I suspected after my investigation, and that's why I thought it might have been a Qt bug. Or anyway, something controlled by Qt, which needs to be massaged with the correct flags.

I'll see if I can find the time to play with it a bit more during Christmas break.

[Ocawesome101]

For what it's worth, I'm also seeing this issue consistently on Plasma Wayland (KWin, non-tiling). Just another data point.

[Eism]

Also might be related to #11244

[eshom]

Can confirm this issue on openSUSE tumbleed (snapshot 20221220) using KDE Plasma wayland.

[LGFae]

But for us, it is crucial that popups are not bounded to the main window, in many cases. Therefore we were forced to build a custom solution.

Do those include these kind of dropdown windows? I can understand it being necessary in many of the other windows musescore creates, but for this particular case, I just can't picture any scenario where it would be necessary for the dropdown window to exceed the main window's borders.

[shimpe]

Same problem on endeavourOs with kde + wayland. It makes musescore very hard to use (e.g. changing instruments in the mixer is only possible using keyboard navigation). I think I read somewhere that wayland does not allow specifying explicit window positions for toplevel windows - could be related to this issue? Are menus toplevel windows?

see https://github.com/gotk3/gotk3/issues/397#issuecomment-522357409

[Gobbel2000]

I'm seeing the same issue with Arch Linux when running on Wayland (tested sway and Plasma on wayland), but Xorg works fine.

One interesting observation is that the appimages don't have the same problem. Could different versions of Qt be the cause?

[ModProg]

Can confirm, Appimage does work (Arch + Sway (wayland))

[kanashimia]

One interesting observation is that the appimages don't have the same problem. Could different versions of Qt be the cause?

Because they don't have wayland support and are run through Xwayland. For your custom builds you can set environment variable to achieve same behaviour QT_QPA_PLATFORM=xcb mscore

@rzvncj i'm sure it is the same on gnome, tested it on mutter and same issue occurs, verify that your musescore actually uses wayland.

---

It is obvious that the issue always occurs when using wayland qt platform, please stop repeating the same thing.

[rzvncj]

@rzvncj i'm sure it is the same on gnome, tested it on mutter and same issue occurs, verify that your musescore actually uses wayland.

I'm not using Wayland. I'm on X11.

[kanashimia]

Useful resources about qt wayland porting:

1. https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes
2. https://blog.martin-graesslin.com/blog/2015/07/porting-qt-applications-to-wayland

[shimpe]

Because they don't have wayland support and are run through Xwayland. For your custom builds you can set environment variable to achieve same behaviour QT_QPA_PLATFORM=xcb mscore

Yes, this works around the issue.

[ntninja]

QML menus and popups can only live inside the main window; they can't exceed its borders. This is because they are no real menus in a real popup window, but they are not more than graphical drawings inside the main window. But for us, it is crucial that popups are not bounded to the main window, in many cases. Therefore we were forced to build a custom solution.

That is very unfortunate. I can totally understand why this NIH approach was taken by MuseScore developers then. Hope I didn’t sound offensive in any way with my previous “this wasn’t a good idea” comment!

QML MenuBar (from QtQuick.Controls) is also just a graphical drawing inside a window, so it wouldn't fix any integration with the system's native menubar. What might work is the MenuBar from Qt.labs (https://doc.qt.io/qt-6/qml-qt-labs-platform-menubar.html). But most probably that will only work on some Linux distros with some window managers, if any at all, so we can't fully switch to it on Linux.

Yes, it will only work on Linux desktops with global menu integration. It would make sense implement it in addition to the look-alike menubar that you are currently rendering, since using it doesn’t break anything if that desktop feature isn’t available, then provide a keyboard shortcut (Ctrl+M, like KDE apps) to hide the look-alike menubar on-demand. From the API docs I’ve read it does not appear as if it provides any native way to check if the global menu is currently being displayed, although the underlying APIs do provide that capability.

The creation of the popup/menu window is still managed via Qt, so we don't have much control about how the native window is created exactly. There is a chance that you can fix this by playing with the so-called window flags of the QWindow.

I might do that, along with exposing the global menu through the Qt.labs API. No promises though.

[plastmassor33]

Here's the specifically global menu related issue: https://github.com/musescore/MuseScore/issues/15473

[mathialo]

For what it's worth, I'm also seeing this issue consistently on Plasma Wayland (KWin, non-tiling). Just another data point.

Thought I'd chime in with a similar remark. Also hitting this same issue on Arch running KDE and Wayland (so kwin as the window manager).

[mxj4]

It might be related to this bug https://bugreports.qt.io/browse/QTBUG-85297 , it's fixed in Qt 6.4+.

[danielzgtg]

No fix for Qt5

KDE fixed it in their apps for Qt5. We can fix it the same way they did.

Qt6 Qt5 since the product is EOL.

I'm not installing Qt6 as long as I'm stuck on Plasma 5. I don't want to risk Qt5 breaking KDE and other desktop integrations like input methods.

Once Plasma 6 comes out and my other required stuff moves to Qt6, I will stop caring about Qt5.

[chunga2020]

Yet another datapoint: It happens in Qtile on Wayland, but not Qtile on Xorg. Tested on latest nightly AppImage:

OS: Arch Linux, Arch.: x86_64, MuseScore version (64-bit): 4.1.0-231820502, revision: github-musescore-musescore-7185eb8

[cbjeukendrup]

It might be related to this bug https://bugreports.qt.io/browse/QTBUG-85297 , it's fixed in Qt 6.4+.

It looks like this fix was cherry-picked to the KDE-patched version of Qt 5.15; there is a small chance that we will switch to that at some point.

But I do have some doubts whether it's really related to that Qt bug; in this issue, the problem seems to be that the menu appears really in the center of the screen, rather than in some random location. Not sure if that's just incidental or that that means that it's a different issue.

[kbloom]

Well, if this has been patched into Manjaro's Qt 5.15 package, then it's clearly not working with the Musescore package that they distribute. Would you by chance know which KDE commit this is, or whether it's been distributed by Manjaro or Arch yet?

[cbjeukendrup]

It seems to be this commit: https://invent.kde.org/qt/qt/qtwayland/-/commit/6481efa9a8fe88043d931648d72dceeeb91af64d

[bfields]

For what it's worth, I can also reproduce on Fedora 39 (with Gnome and Wayland). https://bugzilla.redhat.com/show_bug.cgi?id=2250564

[rriemann]

I can reproduce the bug with:

OS: openSUSE Tumbleweed 20231108, Arch.: x86_64, MuseScore version (64-bit): 4.1.1

The proposal QT_QPA_PLATFORM=xcb mscore fixes the problem, but now everything is very small.

Edit: I added also QT_SCALE_FACTOR=1.5. With that, it works quite well for me.

[KorigamiK]

I can also mention this bug happening on hyprland (wayland) where the drop down menus open as separate windows at the center of the screen.

[napaalm]

@cbjeukendrup is there any update?

[cbjeukendrup]

Not really unfortunately. You could try if the master nightly builds change anything about this, because those use Qt 6.2.4 instead of 5.15. https://musescore.org/en/nightly-builds

[chunga2020]

I'm using a MU4.3 prerelease, and things seem okay, if you want to try the nightlies @napaalm .

Version info (Help > About MuseScore Studio): OS: Arch Linux, Arch.: x86_64, MuseScore Studio version (64-bit): 4.3.0-241100504, revision: github-musescore-musescore-89d32c7

Environment: Sway 1.9 on kernel 6.8.7-arch1-1

[cbjeukendrup]

4.3 is in terms of technologies not very different from 4.2.1 though. The switch to Qt 6 is only part of 4.4 (master).

[gucio321]

In on master right now and still have this issue

[thegreyshadow]

Confirmed here. I had to force starting the app through XCB in order to get menus resembling something normal. However, I lose the ability to go through menus with the cursor keys. I stil can navigate with the keyboard inside a single menu (e.g., File) but cannot go from one menu to another (e.g., from File to Edit).

Operating System: Slackware 64 current KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.6.3 Kernel Version: 6.9.1 (64-bit) Graphics Platform: Wayland

[kamazeuci]

Confirmed here

Operating System: EndeavourOS KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.6.30-2-lts (64-bit) Graphics Platform: Wayland

MuseScore version (64-bit): 4.2.1-, revision: github-musescore-musescore- using Qt version 5.15.13.

[gucio321]

works for me on 2cb22967dab2843a91bff01e6322432a7997375c

[cbjeukendrup]

The master branch now uses Qt 6.2.4 instead of 5.15.x, which may have resolved this. Would be great if more people could try, so that we can close this issue.

Edit: apparently I also said that before, and back then it turned out to be irrelevant, so it must be something else 😅

[Gobbel2000]

Unfortunately the problem hasn't changed for me in the latest master with Qt 6.2.4.

But this Qt bug, which was linked in this thread earlier is only fixed in Qt 6.4+. I would expect that this is the underlying issue.

[kanashimia]

But this Qt bug, which was linked in this thread earlier is only fixed in Qt 6.4+. I would expect that this is the underlying issue.

This issue still occurs on MuseScore master and Qt 6.7.1 Had to do some patching to build with new Qt.

Nix code

```nix stdenv.mkDerivation (finalAttrs: { pname = "musescore"; version = "4.4.0-unstable"; src = inputs.musescore; cmakeFlags = [ "-DMUSESCORE_BUILD_MODE=release" "-DMUE_BUILD_CRASHPAD_CLIENT=OFF" "-DMUE_COMPILE_USE_SYSTEM_FREETYPE=ON" "-DMUE_COMPILE_USE_SYSTEM_TINYXML=ON" "-DMUE_COMPILE_USE_SYSTEM_OPUSENC=ON" "-DMUE_COMPILE_USE_SYSTEM_FLAC=ON" "-DMUE_COMPILE_BUILD_MACOS_APPLE_SILICON=ON" "-DMUE_COMPILE_INSTALL_QTQML_FILES=OFF" "-DMUSE_MODULE_DRAW_USE_QTFONTMETRICS=ON" ]; qtWrapperArgs = [ "--prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath [ libjack2 ]}" "--set ALSA_PLUGIN_DIR ${alsa-plugins}/lib/alsa-lib" ]; nativeBuildInputs = [ qt6.wrapQtAppsHook cmake pkg-config ninja ]; buildInputs = [ libjack2 freetype lame libogg libpulseaudio libsndfile libvorbis portaudio portmidi flac libopusenc libopus tinyxml-2 alsa-lib qt6.qtbase qt6.qtnetworkauth qt6.qtdeclarative qt6.qtdeclarative qt6.qtsvg qt6.qttools qt6.qt5compat qt6.qtscxml qt6.qtwayland ]; postPatch = '' substituteInPlace src/project/internal/projectactionscontroller.cpp \ --replace-fail \ '#include "cloud/clouderrors.h"' \ '#include "cloud/clouderrors.h" #include "cloud/cloudqmltypes.h"' substituteInPlace src/appshell/view/navigableappmenumodel.cpp \ --replace-fail \ 'QList keys = QKeyMapper::possibleKeys(correctedKeyEvent)' \ 'QSet keys; for (auto key: QKeyMapper::possibleKeys(correctedKeyEvent)) keys << key.toCombined();' \ --replace-fail \ 'QList keys = QKeyMapper::possibleKeys(&fakeKey)' \ 'QSet keys; for (auto key: QKeyMapper::possibleKeys(&fakeKey)) keys << key.toCombined();' \ --replace-fail \ 'return QSet(keys.cbegin(), keys.cend());' \ 'return keys;' ''; postInstall = '' rm -r $out/{include,lib} ''; doCheck = false; }) ```

[dgcampbe]

If it is at all helpful to know, for me the issue doesn't occur normally in the Flatpak version (as it does in my distro's repo version as described above), but I can recreate the issue in the Flatpak version using Flatseal to disable X11 and enabling Wayland.

[Potajito]

Same issue on 4.3.2 on arch. Forcing xwayland with QT_QPA_PLATFORM=xcb worksaround that.

KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.9-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3080/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X570 AORUS PRO System Version: -CF