Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qt 6.5+: docks do not open after the last dock on a panel is closed #24866

Open
4 tasks done
orivej opened this issue Sep 22, 2024 · 4 comments
Open
4 tasks done

Qt 6.5+: docks do not open after the last dock on a panel is closed #24866

orivej opened this issue Sep 22, 2024 · 4 comments
Assignees
Labels
Qt-next Either broken or fixed by (updating to) newer Qt versions than we currently use UI Visual issues affecting the UI (not notation)

Comments

@orivej
Copy link
Contributor

orivej commented Sep 22, 2024

Issue type

UI bug (incorrect info or interface appearance)

Description with steps to reproduce

This issue only happens with Qt 6.5+ (tested on Qt 6.7.2). Previously discussed a bit in the comments of #24097

Description: When you open a score and attempt to open a dock that does not have a panel (e.g. you try to open piano or mixer, or you close all of the tabs on the left - palettes, properties, etc. - and try to open one of them back) visually nothing changes, the dock does not open. (@adam248 has also reported this issue as NixOS/nixpkgs#343456)

Explanation: KDDockWidgets 1 (including the latest 1.7) are designed to restore docks incompatibly with the way Qt 6.5+ works.

When MuseScore calls setVisible(true) in DockBase::open to show a previously closed dock widget those panel was also closed, the expected call chain to recreate the panel (frame) is this:

muse::dock::DockWindowActionsController::toggleOpened
muse::dock::DockWindow::toggleDock
muse::dock::DockBase::open
KDDockWidgets::QWidgetAdapter::show
QQuickItem::setVisible(true)
QQuickItemPrivate::setVisible(true)
QQuickItemPrivate::setEffectiveVisibleRecur(calcEffectiveVisible()/*=true*/)
QQuickItemPrivate::itemChange
KDDockWidgets::QWidgetAdapter::itemChange
KDDockWidgets::DockWidgetQuick::event
KDDockWidgets::DockWidgetBase::onShown
KDDockWidgets::DockWidgetBase::Private::maybeRestoreToPreviousPosition
KDDockWidgets::DockWidgetBase::Private::restoreToPreviousPosition
KDDockWidgets::LayoutWidget::restorePlaceholder
KDDockWidgets::DefaultWidgetFactory::createFrame

However, in Qt 6.5 and later the chain ends at QQuickItemPrivate::setEffectiveVisibleRecur since after qt/qtdeclarative@d1b9a4c calcEffectiveVisible() returns false for an item without a parent (and a dock without a panel has none).

KDDockWidgets have redesigned this in KDAB/KDDockWidgets@764385d which went into the 2.0.0 release. Updating to the latest KDDockWidgets (it still supports Qt 6.2+) seems to be the best way forward.

Note: If I revert qt/qtdeclarative@d1b9a4c, the closed docks are opened back again, and the only remaining issues with MuseScore 4.4.2 on Qt 6.7.2 that I see (after #24326 is merged) are:

  1. The mixer dock is almost blank (only channel strip separators are visible) until I switch to a different dock in the same panel and back (e.g. by pressing 'p' twice to open and close piano keyboard).

  2. The navigator dock is a white rectangle the first time it is opened (as long as it was closed when the MuseScore has opened the score) until it is redrawn, e.g. until I pan the view of the score or resize the window.

Supporting files, videos and screenshots

image

In this state P, F7, F8, F9, F10, F12 do nothing with the UI, while the console prints e.g.

| INFO | main_thread | ActionsDispatcher::dispatch | try call action: toggle-piano-keyboard
| INFO | main_thread | ActionsDispatcher::dispatch | try call action: dock-toggle

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

4.4.2

Regression

No.

Operating system

NixOS

Additional context

No response

Checklist

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

orivej commented Sep 22, 2024

I have extracted the custom patches made in MuseScore for KDDockWidgets here orivej/KDDockWidgets#1. This will be useful to make sure that none of the fixes and improvements are lost during update to KDDockWidgets 2

@cbjeukendrup
Copy link
Contributor

That's very useful, thanks!
Before we do duplicate work, were you also planning to try updating MuseScore to KDDW2.1, or shall we do that?

@orivej
Copy link
Contributor Author

orivej commented Sep 22, 2024

I'll give it a try - debugging this issue made me learn quite a lot about KDDW and the way MuseScore uses them.

@cbjeukendrup cbjeukendrup mentioned this issue Sep 22, 2024
4 tasks
@cbjeukendrup
Copy link
Contributor

@orivej That's awesome! I'll assign you for now, but please don't feel pressured in any way.

@cbjeukendrup cbjeukendrup assigned orivej and unassigned Eism Sep 23, 2024
@cbjeukendrup cbjeukendrup added the Qt-next Either broken or fixed by (updating to) newer Qt versions than we currently use label Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Qt-next Either broken or fixed by (updating to) newer Qt versions than we currently use UI Visual issues affecting the UI (not notation)
Projects
Status: In Progress
Development

No branches or pull requests

4 participants