[MU4 Issue] Menu bar Doesn't behave like a normal menu bar

[lomenzel]

Describe the bug A short and clear description of what the bug is: The Menubar is always visible in the Application menu. Even if Global menu is enabled in a Panel It looks like this:

Expected behavior (another application):

To Reproduce Steps to reproduce the behavior:

• i use KDE Plasma 5.26.4 on KDE Neon.
• installed the application via the AppImmage provided on the Musescore website
• added global menu to the plasma-panel
• every app has their menu now in the global menu and not in the application window, exept musescore

[plastmassor33]

Here's the same issue described on the forums: https://musescore.org/en/node/337348

I too would love to see global menu working on linux.

[cbjeukendrup]

I expect that this is doable using https://doc.qt.io/qt-5/qml-qt-labs-platform-menubar.html (which we already use on macOS). I think the difficulty is: how an we detect if the system supports a system menu bar? So basically, we need a way to determine whether we need to show our own in-window menu bar, or that there is a system menu bar.

[plastmassor33]

I have absolutely no technical knowledge in this, but this seems to happen automatically. i.e.: you put the 'global menu' widget on a panel in KDE and the menu gets extracted from the window by the DE and put where the widget is located. The same is with the Unity desktop. The program only has to expose it's menu as a 'menu' to the DE. Qt apps almost always work this way (MU4 being the only exception I'm aware of, to be honest, apart from the new Qt6 apps that are not yet supported properly by KDE)

Perhaps these links could help: https://develop.kde.org/hig/components/navigation/menubar/#code https://blog.broulik.de/2016/10/global-menus-returning/

[ntninja]

@plastmassor33: That it “seems to happen automatically” is strictly from a user PoV. :wink:

Unfortunately it does not look like the Qt.labs API provide the capabilities to do this automatically, as I mentioned in https://github.com/musescore/MuseScore/issues/15285#issuecomment-1368494118:

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.

However, some probing reveals that it’s really the presence of the ”com.canonical.AppMenu.Registrar” D-Bus service (whether that name has been acquired or not) that causes KDE applications to show or hide their native application menus. So the logic from MuseScore’s PoV can be:

1. Call “org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.NameHasOwner” with argument “"com.canonical.AppMenu.Registrar"”
2. If the call returns true, use the Qt.labs API for exposing the menu like on macOS
3. If the call returns false, use the AppMenuBar like on Windows
4. Bonus points: Subscribe to the “org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.NameAcquired” and “… org.freedesktop.NameLost” signals to dynamically change the backend based on current user preference changes (KDE apps don’t do this)

[adazem009]

@plastmassor33: That it “seems to happen automatically” is strictly from a user PoV. wink

Unfortunately it does not look like the Qt.labs API provide the capabilities to do this automatically, as I mentioned in #15285 (comment):

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.

However, some probing reveals that it’s really the presence of the ”com.canonical.AppMenu.Registrar” D-Bus service (whether that name has been acquired or not) that causes KDE applications to show or hide their native application menus. So the logic from MuseScore’s PoV can be:

1. Call “org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.NameHasOwner” with argument “"com.canonical.AppMenu.Registrar"”

2. If the call returns true, use the Qt.labs API for exposing the menu like on macOS

3. If the call returns false, use the AppMenuBar like on Windows

4. Bonus points: Subscribe to the “org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.NameAcquired” and “… org.freedesktop.NameLost” signals to dynamically change the backend based on current user preference changes (KDE apps don’t do this)

I simply create a dummy QMenuBar in my application. It provides a nativeMenuBar property which can be used to check whether the application displays the native menu bar. https://doc.qt.io/qt-6/qmenubar.html#nativeMenuBar-prop

I've made a method to check for native menu bar and I hide the QML-based menu bar if it returns true. https://github.com/Open-Typer/Open-Typer/blob/1e7ba92804ae0b783dc9321e395628d3e74a5eef/libcore/src/QmlUtils.cpp#L50-L55

It works fine in KDE Plasma and on macOS. However, I've noticed that changing the language dynamically and retranslating the UI causes the native menu bar to "freeze" so it can't be opened anymore. But maybe that's just a bug in my application, or a bug in Qt.

Also note that the native menu bar will even display on Windows, but it's a QMenuBar placed on top of the window, so make sure to disable native menu bar completely for Windows.

[ntninja]

@adazem009: Nice work! :grin: