Qt 5.15 vs 6.x for MuseScore 4.x development

There is no reason to assume Qt 6 / Musescore 4 won't run on the 64-bit versions of Windows 7, 8 or 8.1 though (even if only the last of those is still supported by Microsoft). It may not be supported, but should still run, same way as MuseScore 3.x still runs on Windows 7, regardless of having been released after Microsoft dropped support for it.

QT 6.2 is LTS only for paid QT customers

Thank you Riaan for this post, giving a quite complete view of the situation.

Here are my thoughts:
- We as community members can start a discussion, but the decision will be made by the lead developers (Vasily and Igor) together with Martin (as the product owner), and as far as I know, this is not a very actual subject right now because we are focused on building the features of MU4.
- MU4 is already a huge release, which is almost impossible to work flawlessly from the beginning. It would not surprise me if the in-house developers would be reluctant about switching to a new major Qt version at the same time.
- However, as I have experienced myself, the changes that need to be made in our code are not that big, so the amount of problems caused won’t be big either. There are a couple of things (which I summed up in the MuseScore Discord server) though that are removed from Qt 6 and for which we need to find or create a replacement.
- There is no big need to switch to Qt 6 right now. There are no big new features that we need to use or that would make life much easier. In fact, the things that are removed from Qt 6 make life quite difficult ;-). The longer we delay the switch, the more difficult it will be though, and I consider it a good practice to use supported and up-to-date dependencies.
- I do think it is better to make this switch for a major version bump. I don’t expect MuseScore 5 soon enough to delay it until then.
- MuseScore is getting a lot more professional, so I’m my opinion, it could be justified to set system requirements a bit higher.
- I can’t estimate very well how bad it is to drop Windows 32 but support. For me as a Mac user, 32 bit sounds ancient because Apple rigorously killed everything 32 bit some years ago, but for Windows, that might be very different.

I’m not sure whether this is the best place for this discussion because I believe the developers don’t come here very often. But when something significant happens on GitHub or Discord, we could post updates here, to keep the community informed.

Last thing: I realise that this may be a sensitive topic for some people. Let’s keep this discussion constructive. To people who are worried by this: don’t worry too much, because nothing has been decided yet.

By now, Qt 6.2 has been released, which is the first version of Qt 6 that we could consider to use.

During the past time, I have been doing some more work on adapting MuseScore for Qt 6, and I must say that I'm slightly loosing my optimism about it (if I had any). I'm relatively close to getting it working, but at the same time still far off.

Some crucial things are removed (often without replacements):
- QtGraphicalEffects (mainly used for drop shadows, but also for gradients)
- XML schema validation (used for MusicXML import; we could probably do without schema validation, but I guess it's better to keep doing that, so we would need to pull in another third party XML library)
- QtQuick.Controls 1 (which was the only way to get some sort of TreeView, and which we also used for some TabBar items, but for tab bars there are replacements);

Many things got only more complicated:
- QVariants and QMetaTypes somewhat (but I think we should stop using those anyway)
- QStringRef is replaced with QStringView. QXmlReader (which we are using for reading scores and more) worked with QStringRef, so it now works with QStringView. The problem with QStringView is that you can't easily compare it to a plain c string literal, which is something we need to do very often. So with Qt 6 we need to convert from QStringView to QString over and over again, each time we need to compare something.
- Some things with QChar became slightly more strict; now, you can't implicitly convert an integer to a QChar anymore.
- In QML, if you have a signal that has parameters, you now need to explicitly declare those parameters in the corresponding signal handlers, which might make the code somewhat clearer, but it also requires more typing and you have to remember it every time.
- QML already had the constraint that type names must start with an uppercase letter and other names must start with a lowercase letter, which makes some sense and is common practice anyway. But now they are making it much worse: "value types" should start with a lowercase letter, while "reference types" should still start with an uppercase letter. That could also make a little bit of sense, but it has some very unwanted consequences for our naming scheme (the problem is that we are misusing structs with Q_GADGET to register enum types to QML, and we want those enum types to start with a capital letters, but Qt classifies them as "value types", so rebels against that. There is a bit more to say about this, but I'll leave that for now.)

And there are probably other things I'm forgetting now...

I have already found crashes in QML that didn't occur with Qt 5.
- It crashes in QItemSelectionModel::hasSelection (in the Palettes module)
- Using the header property of ListView in the MixerPanelSection also causes a crash.
So, even though it's already 6.2 LTS, it's still not stable.

And some things suddenly don't work anymore; some icons do not show up, our GridViewSectional (used for NoteInputBar) does not work anymore, and QML inside QWidgets is not possible anymore (unless you change the rendering options).

So, repairing all these things will definitely take time. My estimation is that the switch to Qt 6 certainly won't happen before MuseScore 4.0. I will leave it to the team to decide whether the minimum macOS version for MU4.0 should be 10.14 (so that all Mac users who can have MU4.0 can have MU4.1 too) or 10.13 (so that as many users as possible can have MU4.0, and less users can have MU4.1).

The problem would be a lot easier if Qt could lower its system requirements. But I guess that won't happen.

Maybe it is good to point out that the end user will not notice any (significant) difference when we would use Qt 6 (except for the system requirements). Doubtlessly, there will be slight performance improvements, but I don't think that's worth it.

From the developers point of view, there are some improvements (some things become a bit easier, safer, more efficient), and the expectation is that there will be even more exciting improvements in subsequent versions of Qt 6. But as said, there are also downsides. Another important reason to choose for Qt 6 is just that it is a supported version right now, while 5.15.2 is end-of-life. But as long as 5.15.2 has no bad bugs (and it has no, as far as we know), there is not much wrong with using it.

News: Qt 6.2.1 has been released and fixes the QItemSelectionModel crash I mentioned in the previous post. So that gives some new hope.

Another thing to consider:
Qt Creator is the "integrated development environment" (IDE) that is often used to build Qt apps. I also use it for MuseScore. Some weeks ago, Qt Creator 6.0 beta 1 came out. Qt Creator itself is also built with Qt, and this new version uses Qt 6.2, which means that it runs natively on my M1 Mac. I tried it out, and it makes a huge difference in speed. The Intel/Rosetta version took 10-15 seconds to launch and load MuseScore, the native version takes only 1-5 seconds.

It is absolutely not said that the speed improvements will also be that significant for MuseScore, but it was certainly an eye-opener to me.

So while the move to Qt 6 would be disadvantageous for users of old Macs, users of new Macs probably will benefit from it.

Something similar goes for Windows: only Qt 6.2/6.3 will support Windows 11.

(It must be said though that "supported" only means that there is some chance that issues that are found will get fixed, while with unsupported versions you can be quite sure that issues won't be fixed. Also, the Qt company says that they have not found big issues on Windows 11, and the few they did find do not have to do with the technologies we use, so this in itself is not a reason to switch either.)

How about the Linux situation with respect to Intel vs ARM? We never had an official ARM build of MuseScore 3 for ARM but @ABL got one working, and it’s a great thing for Chromebook users. Will this be viable for MuseScore 4? In particular, is Qt 5.15 available for that platform?

By the way, see https://github.com/musescore/MuseScore/pull/10108, which contains all changes necessary for Qt 6.

Apparently, Qt 5.15 CAN be built for Apple Silicon.

See https://www.qt.io/blog/qt-on-apple-silicon
"Some patches already went into Qt 5, so Qt 5.15.4 and above should build and run by passing -device-option QMAKE_APPLE_DEVICE_ARCHS=arm64 to configure".