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 gotk3/gotk3#397 (comment)

[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:
#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

[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

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<int> keys = QKeyMapper::possibleKeys(correctedKeyEvent)' \
        'QSet<int> keys; for (auto key: QKeyMapper::possibleKeys(correctedKeyEvent)) keys << key.toCombined();' \
      --replace-fail \
        'QList<int> keys = QKeyMapper::possibleKeys(&fakeKey)' \
        'QSet<int> keys; for (auto key: QKeyMapper::possibleKeys(&fakeKey)) keys << key.toCombined();' \
      --replace-fail \
        'return QSet<int>(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

[guilletrejo]

Also happening on 4.3.2 on openSUSE TW:

KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2
Kernel Version: 6.10.3-1-default (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5600 6-Core Processor
Memory: 15.5 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2
Product Name: A320M-HDV R4.0

And @Potajito workaround also solved it for me!

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

[cbjeukendrup]

Perhaps it's not very productive if we keep growing this thread with "me too" comments, mentioning the same workaround over and over again.
As said, it looks like we cannot do anything about this because we fully rely on Qt for the window creation. Perhaps it can be corrected by setting some window flags or setting the parent of the window or not, but that requires some experimentation so should ideally be done by someone who can reproduce this bug (and apparently, there are plenty of people who can, unfortunately).

[kbloom]

I saw a potentially relevant comment about the XDG positioner protocol in a blog post by one of the KDE devs today at https://blog.broulik.de/2024/08/a-fresh-perspective-on-things.

I put a comment asking him whether he knows anything that can help us.

[kbroulik]

I’ve had a quick look: your popups aren’t Qt::Popup windows [1]. In order for XDG positioner to work, the window needs to be of popup type. You also always need a transient parent for the window (QWindow::setTransientParent).

Sadly, I don’t even get a menu bar, it’s just a blank strip at the top when I launch the app, so I cannot investigate what’s up with that. But changing the popups to be of actual popup type at least improves the positioning of some popups (e.g. combobox popups) I got in a way that they’re not placed in the middle of the screen anymore. Then you can investigate fixing the positioning code to not assume absolute coordinate anymore.

[1]

MuseScore/src/framework/uicomponents/view/popupwindow/popupwindow_qquickview.cpp

Line 59 in cf7e523

Qt::Tool

[Potajito]

I’ve had a quick look: your popups aren’t Qt::Popup windows [1]. In order for XDG positioner to work, the window needs to be of popup type. You also always need a transient parent for the window (QWindow::setTransientParent).

Sadly, I don’t even get a menu bar, it’s just a blank strip at the top when I launch the app, so I cannot investigate what’s up with that. But changing the popups to be of actual popup type at least improves the positioning of some popups (e.g. combobox popups) I got in a way that they’re not placed in the middle of the screen anymore. Then you can investigate fixing the positioning code to not assume absolute coordinate anymore.

[1]

MuseScore/src/framework/uicomponents/view/popupwindow/popupwindow_qquickview.cpp

Line 59 in cf7e523

Qt::Tool

About the blank strip, I also got that when compiling from git against qt 6.7.2. Maybe something on master is not right, maybe I didn't follow some instructions, but is interesting that we both had the same issue with the blank strip.

[cbjeukendrup]

The blank menubar is a Qt 6.5+ issue (see #23980 (comment) and following comments). That's part of the reason that we're still using 6.2 (the other part of the reason is that we want to support as old macOS versions as possible).

your popups aren’t Qt::Popup windows

Qt::Tool = Qt::Popup | Qt::Dialog though. Do you think we have to drop Qt::Dialog, i.e. switch from Qt::Tool to Qt::Popup?

I'll also look into the TransientParent stuff. In PopupWindow_QQuickView::show, we do set the transient parent but perhaps that's too late?

[kbloom]

So I can't see or test the menubar because I'm building with Qt 6.7.2, but when I changed Qt::Tool to Qt::Popup, it fixed the positioning problem for context menus.

Even though you target Qt 6.2, it would be nice to get the menubar working on the most recent versions of Qt so that Linux distributors who build against the shared system Qt get a working app.

I'm not sure what else I need to test that could be broken by this change.

[cbjeukendrup]

The change might break things on other platforms. But if that is the case, for macOS and Windows, that can be easily resolved using #ifdefs, and if some Wayland-or-not-Wayland detection turns out to be necessary, I assume that must be possible too.
You're welcome to open a Pull Request for this change; then our testers will check it on all platforms. (I could also open the PR, but you and @kbroulik deserve the credits.)

We're indeed planning to investigate the Qt 6.5+ issues in the not-too-far future, partly because of Linux distributors indeed, and partly because eventually we'll have to upgrade anyway.

[Eism]

May be related to #15826. See #24094 (comment)

[kbloom]

This bug is probably not caused by the fix to #15826, considering that this bug is older, and and the fix seems to have nothing to do with how AppMenuBar is implemented. Now if you're talking about the missing menu bar in Qt 6.5+, we should file a separate bug for that, so we don't confused about what we're trying to solve here.

…

On Mon, Aug 19, 2024, 4:43 AM Elnur Ismailzada ***@***.***> wrote: May be related to #15826 <#15826>. See #24094 (comment) <#24094 (comment)> — Reply to this email directly, view it on GitHub <#15285 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANXXKGLRXSOLWRV5JB6MTZSGV3TAVCNFSM6AAAAAATCBZMQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGAYDQMRRGA> . You are receiving this because you commented.Message ID: ***@***.***>

[kbloom]

I'm withdrawing my pull request because the situation with the CLA and my employer is more complicated than I thought, and I don't want to work through it for a one-line patch. @cbjeukendrup Please create your own based on my comment above. I wouldn't necessarily wait for @kbroulik to write it over such a small thing.

[cbjeukendrup]

By the way, is everyone here not using the "official" AppImage, but distro-provided or self-built versions? Because if I'm not mistaken, the AppImage doesn't ship with Wayland support at all (in MuseScore 4.3 and 4.2 at least) so would always fall back to xcb. Not that it matters anything, but I just want to check my understanding about the Wayland situation.

[kbloom]

I prefer to use my distro-provided package, if it works.

[kanashimia]

At least on NixOS it is specifically wrapped with QT_QPA_PLATFORM=xcb, judging by the reports here there are quite a lot of packagers who didn't do the same.
You could prefer xcb platform in the application itself, that's how qpwgraph did it for example, there's no need for all of the distributions to add a workaround to fix this.

I personally want Wayland support for the better mixed monitor handling and scaling.

[cbjeukendrup]

We're currently considering to make Wayland "opt-in" for 4.4, but with this fix, to take a bit more time to ensure that there are no other blocking issues that nobody discovered yet. Then for 4.5 we hopefully have enough confidence to make it default. On the other hand, I wonder how many people will actually use the opt-in in practice. If only few people do it, we'll probably still not get all bugs found and reported. But maybe it works if we encourage people to try it in the release notes. Any thoughts on this?

[MarcSabatella]

By the way, is everyone here not using the "official" AppImage, but distro-provided or self-built versions? Because if I'm not mistaken, the AppImage doesn't ship with Wayland support at all (in MuseScore 4.3 and 4.2 at least) so would always fall back to xcb.

I’m definitely using the AppImage - bizarre errors from unsupported third party builds are definitely not anything I want to deal with. And yes, Wayland was disabled at some point (although I remember it worked originally in initial MU4 builds, other than the menu/popup issues). And that is why I am concerned that it currently is the default - this makes 4.4 worse out of the box than previous MU4 releases, requiring workarounds that were not necessary before.

I’m fine with keeping the option of running under Wayland.

[kanashimia]

If only few people do it, we'll probably still not get all bugs found and reported. But maybe it works if we encourage people to try it in the release notes. Any thoughts on this?

It is okay, it will be enough. It needs at least some testing with different Qt versions and compositors before it becomes the default, and when it does then any major issues will already be delt with. Minor issues can be fixed later. And you can revert the default back to X11 in the hotfix if something goes wrong anyways, although it isn't the nicest thing to do.