Qt 6.5+: menu bar and top-left toolbar are missing

cbjeukendrup commented 2 months ago

Issue type

Other type of issue

Description with steps to reproduce

In development builds made with Qt 6.5 or later, the top-left toolbar (Home/Score/Publish) is missing. Additionally, on OSs without a system-wide menu bar, the menu bar at the top of the window appears as a blank strip.

Although we won't move away from Qt 6.2 in the near future because of macOS compatibility, it would be good to fix this problem, because

eventually, we'll have to update anyway
Linux packagers want to create unofficial distro-specific MuseScore packages against the latest version of Qt, i.e. 6.7.2 at the time of writing, so they suffer from this problem.

Supporting files, videos and screenshots

(from https://github.com/musescore/MuseScore/issues/23980#issuecomment-2282881609)

What is the latest version of MuseScore Studio where this issue is present?

self-built from master with Qt 6.5+

Regression

No.

Operating system

*

Additional context

No response

Checklist

[X] This report follows the guidelines for reporting bugs and issues
[X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
[X] I have attached all requested files and information to this report
[X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

kbloom commented 2 months ago

I inspected this in GammaRay, and appMenuBar had a height of 0. Changing the height in GammaRay to 20 made it visible.

kbloom commented 2 months ago

I didn't see anything obvious in GammaRay when I inspected the top-left toolbar.

darix commented 1 month ago

will there be a patch fix without upgrading Qt to resolve this?

kbloom commented 1 month ago

Some more investigation in AppMenuBar: it appears that

Component.onCompleted: {
  appMenuModel.load()
}

doesn't get run until I change the height of the AppMenuBar to be non-zero, so the ListView in AppMenuBar.qml can't get a non-zero height from its children, because the children haven't been loaded. Chicken and egg.

kbloom commented 1 month ago

I wonder if this commit in Qt is related. https://github.com/qt/qtdeclarative/commit/492dc98a288763d3d026e9557ffadc018cede350

darix commented 1 month ago

04:01:18.566 | ERROR | main_thread     | GuiApp::perform | error: qrc:/qml/Muse/UiComponents/internal/PopupContent.qml:81:5: QML QQuickItem: Binding loop detected for property "implicitWidth"

04:01:18.566 | WARN  | main_thread     | Qt              | qrc:/qml/Muse/UiComponents/internal/PopupContent.qml:81:5: QML QQuickItem: Binding loop detected for property "implicitWidth"

is that related maybe?

darix commented 1 month ago

is the mixer working for you?

Vogtinator commented 1 month ago

AppMenuBar.qml has

ListView {
    id: root

    height: contentItem.childrenRect.height
    width: contentWidth

And that's the only source for sizing, the instantiation using the Loader in Main.qml doesn't set one.

I don't see how this can work, because ListView explicitly documents (https://doc.qt.io/qt-6/qml-qtquick-listview.html#cacheBuffer-prop):

a horizontal ListView only calculates the contentWidth. The other dimension is set to -1.

which means it starts with only contentWidth set (initially "estimated" at 100px * model size, hardcoded at https://github.com/qt/qtdeclarative/blob/a208a60ad8e98d7ecd8795596341284a418650e9/src/quick/items/qquicklistview.cpp#L160) and (https://doc.qt.io/qt-6/qml-qtquick-listview.html#details):

Note: ListView will only load as many delegate items as needed to fill up the view. Items outside of the view will not be loaded unless a sufficient cacheBuffer has been set. Hence, a ListView with zero width or height might not load any delegate items at all.

Means that with no height set, there will not be any children, meaning that the height will never be set either.

To avoid this, it should be enough to start with a non-zero height and then when the delegates are instantiated, use the calculated height:

diff --git a/src/appshell/qml/platform/AppMenuBar.qml b/src/appshell/qml/platform/AppMenuBar.qml
index 1a57ffac7a74..ce7453515a68 100644
--- a/src/appshell/qml/platform/AppMenuBar.qml
+++ b/src/appshell/qml/platform/AppMenuBar.qml
@@ -28,7 +28,7 @@ import MuseScore.AppShell 1.0
 ListView {
     id: root

-    height: contentItem.childrenRect.height
+    height: Math.max(1, contentItem.childrenRect.height)
     width: contentWidth

     property alias appWindow: appMenuModel.appWindow

darix commented 1 month ago

Fix confirmed ... but I guess this also gets hit by https://blog.broulik.de/2024/08/a-fresh-perspective-on-things/

if you click "files" menu and then move the mouse cursor right the new menus open at the start of the menu bar. :)

so now I am wondering ... is there more places where a similar fix to this is needed? like e.g. the mixer isnt working here.

kbloom commented 1 month ago

You could probably grep the codebase to find other issues similar to this.

Looks like we should investigate all of the following:

$ grep -r 'height:.*contentItem' *                                                        
src/framework/extensions/qml/Muse/Extensions/ExtensionViewer.qml:    height: builder.contentItem ? builder.contentItem.implicitHeight : 600
src/appshell/qml/platform/AppMenuBar.qml:    height: contentItem.childrenRect.height
src/appshell/qml/MainToolBar.qml:        height: contentItem.childrenRect.height
$ grep -r 'width:.*contentItem' *
src/project/qml/MuseScore/Project/SaveToCloudDialog.qml:                    width: contentItem.width
src/framework/extensions/qml/Muse/Extensions/ExtensionViewer.qml:    width: builder.contentItem ? builder.contentItem.implicitWidth : 800
src/playback/qml/MuseScore/Playback/internal/MixerPanelSection.qml:            width: contentItem.childrenRect.width
src/appshell/qml/MainToolBar.qml:        width: contentItem.childrenRect.width
src/instrumentsscene/qml/MuseScore/InstrumentsScene/internal/InstrumentsTreeItemDelegate.qml:                width: treeView.contentItem.width

The mixer is definitely on the list.

I can try to write a PR for this tomorrow if nobody gets to it first. If you want to beat me to it, you sidestep the menu positioning problem by testing on X11. I don't think this is a Wayland-specific bug.

hamkg commented 1 month ago

Just confirming that Votginator's patch fixes the missing menu bar issue when building on slackware-current (and running X11).

kbloom commented 1 month ago

I've got PR #24326 for the menu bar and the main toolbar, but trying to make a similar fix in MixerPanelSection doesn't fix the mixer. I'm not sure what's wrong with the mixer.

kbloom commented 1 month ago

Regarding the mixer, I also couldn't get some other panels to open, like the piano keyboard.

kbloom commented 1 month ago

When I tried opening the Navigator, it didn't show any mini-pages until I also opened Braille, at which point Braille doesn't show anything, but the Navigator does.

When I close and reopen Palette, the re-opened palette is empty.

kbloom commented 1 month ago

In short, can you file a separate bug about all of the docks.

cbjeukendrup commented 1 month ago

Speaking of docks: in combination with updating to the latest Qt, we should perhaps also update to the latest KDDockWidgets. That's going to be non-trivial, because we would have to update from 1.5-ish to 2.1 which is a major version update, and also because we're using some private KDDockWidgets headers in order to get the exact behaviour we want.

orivej commented 1 month ago

Speaking of docks: in combination with updating to the latest Qt, we should perhaps also update to the latest KDDockWidgets. That's going to be non-trivial, because we would have to update from 1.5-ish to 2.1 which is a major version update, and also because we're using some private KDDockWidgets headers in order to get the exact behaviour we want.

EDIT: I've moved my comment to a separate bug report #24866

musescore / MuseScore