Update to Qt 6

[cbjeukendrup]

It's one unnoticeably small step for a user, but technologically doubtlessly a huge leap forward.

Actually this is a strange experience: I've been working on it so long, and then it finally compiles and runs, and what you see is just MuseScore 4 but with some extra bugs. 😅
But eventually we will need it.

In the first instance, this PR is not meant to be merged soon. It is a bit like a "proof of concept", and to gather feedback on what I have been working over the past months. I'll rebase this PR occasionally to fix conflicts.

Some notes:

• I tried to split the changes into commits in a way that makes sense. For some changes that are all about the same thing but involve many files, I also created multiple commits, to prevent mistakes. All commits could be reviewed separately.
• Unfortunately, the differences are so big, that we cannot do this in small steps. At most, a few commits could be "backported" to the master branch.
• We really need Qt 6.2.2, because anything older has bugs that cause crashes.
• Merging this PR means saying farewell for good to 32-bit machines and macOS 10.13 and earlier (see https://doc-snapshots.qt.io/qt6-dev/supported-platforms.html)
• I've only tested it on macOS (Intel and ARM) so far.
• If you have a Universal binary of LibSndFile, you should be able to build a Universal version of MuseScore, that runs natively on both Intel and Apple Silicon Macs. I haven't been able to try it yet, but I added a CMake option that should do it.
• We might want to create a arm64 or even better Universal version of the crashpad handler too, but I haven't done that yet.
• For a long time, I tried to do it without the Qt 5 Compatibility module. But finally, I couldn't resist using this "power-up", because it just covers some things we critically depend on that were removed in Qt 6. Specifically, it is used just for QTextCodec in C++ and GraphicalEffects in QML.
• I also had to add the State Machines module, which is no longer included by default. It is only used by the ExampleView class, which I expect to be removed at some time, so we can remove the State Machines module when that happens.
• The biggest problem for which I don't see a solution, is that the XML Patterns module is removed. We depend on it for (Music)XML schema validation. I'm afraid that the only options are either removing the validation, or pulling in another third-party dependency.
• In XML reading code, we often need to compare QStringViews with string literals. Now, I'm doing that by converting the QStringView to a QString using toString(), and then comparing the QString with the string literal, but I realized/found out later that other ways might be more efficient, such as comparing the QStringView from the Xml reader to another QStringView created from the string literal, or using the QStringLiteral macro. We might revise that later.
• For the rest, at the C++ side, I believe everything is working without problems.
• The unit tests are passing.
• In QML, most things are working. There are a few problems:
  • Big problem: QtQuick.Controls 1 got removed, and Qt 5 Compatibility offers no alternative. We used it for tab bars in the Inspector and for TreeView in the Instruments panel and the Preferences dialog. Of course, for tab bars, QtQuick.Controls 2 has a replacement (albeit significantly different, but OK), but for TreeView, there is nothing. So I have temporarily replaced it with a ListView, which means that we can't expand items. There are various external solutions, such as the one at https://marketplace.qt.io/products/treeview, which is also available under a GPLv3 license, but I'm not sure whether and how we can make use of it.
  • Semi-big problem: QQuickWidget is not available because something changed to how QML is rendered. See https://doc.qt.io/qt-6/quick-changes-qt6.html#changes-to-qquickwidget. Using QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGLRhi) as they suggest produces such bad results that it is not a viable option, so we can't mix QtQuick and QWidget in one dialog anymore. So we'd better rewrite the EditStyle Dialog completely...
  • Semi-big problem: SortFilterProxyModel does not work correctly anymore in some cases; setting the source model seems not to trigger the proxy model to do its work. For the note input bar, I rushed in a temporary fix, because it made the app unusable. See the commit message for some details.
  • (I'm doubtlessly forgetting some things that I'll fill in here when I remember again)
  • Small problem: we now use DropShadow from Qt5Compat.GraphicalEffects, but it behaves a bit different. It is clipped at the bounds of its source item. Workaround is to wrap the source item into another Item with some padding, and setting that wrapper item as the source.
  • Small problems: some qml items behave slightly different in some cases. For example, I had to fix some strange binding loops I didn't recognize from Qt 5.
  • No problem: almost surprisingly, the Timeline, which is basically a QWidget inside QML, still works great.
• I temporarily disabled the CI workflows, because I can't do everything that is needed to update them, and also to save resources and costs when force-pushing, which I expect to be doing often.

Statistics:

• This is my 200th PR at MuseScore 🥳
• The number of files changed (originally 573) is certainly the biggest in a PR of mine so far, the number of lines changed probably not.
• I have apparently deleted more lines than I added, while I had the feeling that the changes mainly complicated the code.

Resolves: #9951
Resolves: https://musescore.org/en/node/323841

[igorkorsukov]

This is my 200th PR at MuseScore

Congratulations!!

I think that many changes can be merged separately right now, which do not directly depend on Qt6.
For example "Farewell QStringRef", "Replace QScopedPointer with std::unique_ptr" and so on
It would be great to make most of these changes in advance, by separately PRs.

[cbjeukendrup]

This is my 200th PR at MuseScore

Congratulations!!

I think that many changes can be merged separately right now, which do not directly depend on Qt6. For example "Farewell QStringRef", "Replace QScopedPointer with std::unique_ptr" and so on It would be great to make most of these changes in advance, by separately PRs.

Thanks!
With QStringRef specifically, that is a problem, because in Qt 5.15 the QXmlStreamReader just returns QStringRef and not QStringView. And for the rest, there were not that many uses of QStringRef, or they were indirectly related to the Xml Reading code.
But indeed there are a few other cases, like the std::unique_ptr example, which can be done separately. I'll be doing that the coming time.

[cbjeukendrup]

Quite good news: Qt 6.3 alpha is released and contains a brand new TreeView component. That was one of the big missing things at the QML side! I will install this alpha version and try if the new TreeView component can help us.

[cbjeukendrup]

Ok, I experimented with it for a while. It definitely has much potential to be helpful, so that's a relief. But as soon as we start expanding and collapsing rows as in the Preferences dialog, it goes totally crazy. And dragging rows in the Instruments Panel is even worse. Fortunately, it's still alpha software, so there's hope that it will improve...

[cbjeukendrup]

It's time to say farewell to this PR; mainly because I want to free up the qt6 branch name prefix in my fork :)
But also because this PR has served its purpose: the switch to Qt 6 has (almost) been completed, quite successfully! Most commits that are still left here only remove QT5_COMPAT checks, which I will do gradually and systematically in next PRs. Some other commits are small refactorings that can also be done in separate PRs. And then some more commits are about possibly going beyond Qt 6.2.4; those could be moved to a new branch and a perhaps new PR to get attention, hoping we can crowd-source some fixes for the mysteries that Qt 6.5 seems to introduce.