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

• Aug 15, 2021 - 17:56

For background:

  • We are tracking various OS and Qt versions against MuseScore versions at Developer's handbook - Versions Reference, including a section for Macs (by year of release) and maximum macOS version) . All of the below are deduced / referenced from tables from this page.
  • What will become MuseScore 4.0 is currently being developed with Qt 5.15.
  • MuseScore (4.x) on Qt 5.15 already drops support for MacOS 10.10, 10.11 & 10.12 (compared to what MuseScore 3.6.2 on Qt 5.9 supported. It does not drop any Windows versions when compared with MuseScore 3.6.2 on Qt 5.9.
  • There is mention of switching development to Qt 6.x, as per
    https://discord.com/channels/818804595450445834/818848130027880479/8757…
  • As per the Qt Roadmap for 2021, QT 6.2 is expected to be the first Qt 6.x Long Term Support version, and expected in September 2021.
  • MuseScore (4.x) on Qt 6.0/6.1 would drop support for MacOS 10.13 as well. However, more importantly, it only supports Windows 10 64-bit, e.g. it would be dropping support for

    • Windows 7, 8 (32-bit and 64-bit)
    • Windows 10 (32-bit)
    • Also, not having a 32-bit binary would also impact PortableApps.com, which has a strong preference for the 32-bit binary (which is more universal, because it runs on 64-bit Windows as well)

Question: Should we switch to QT 6.x as soon as possible, e.g. before releasing MuseScore 4, or only on a subsequent minor release (MuseScore 4.1, 4.2, etc.)?

The argument for delaying the switch to Qt 6.x:

  • There are a lot of Windows PCs and pre-2012 Macs and which would be stranded if the switch to a later Qt version were to happen sooner rather than later.
  • The effort to port from Qt 5.15 to 6.x (?)
  • Waiting for Qt 6.2 LTS to be released and stabilised.

The argument for switching to Qt 6.x sooner rather than later

  • Support for Qt 5.15 will end before Qt 6.2.
  • Avoid confusion by having a minor release drop support for operating systems - With MuseScore versions 1, 2 and 3, everything that was supported with the first release of a major version (1.0, 2.0, 3.0) continued to be supported for the minor releases, 1.3, 2.3, 3.6), since the Qt version did not change mid-major version.

My personal opinion (as a community member, not a developer - I don't have the full picture, nor am I aware of the development impact of delaying) would be

  • To delay as long as possible and manage the communication (and possible confusion) as best as possible, to be as inclusive as possible. For example, even if we end up releasing a 4.0.x which is reasonably stable to all these legacy operating systems, before the work on 4.1 (which breaks the compatibility), begins. it may be preferable than having those legacy operating systems stuck on MuseScore 3.6.2.
  • Another option would be to bump the version number to MuseScore 5 much sooner, as part of which the development environment is refreshed to Qt 6.2 LTS and support for legacy operating systems is dropped.

Let's have the discussion. At least the community (and those potentially excluded by the decision) will have some insight into the decision.


Comments

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.

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.)

In reply to by cbjeukendrup

> 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 assume you're talking about the downloadable official builds? AFAIK Qt 5 can be built on Apple silicon (possibly even with some acceleration because of the long-standing support for iOS), so MuseScore could ship with custom-built Qt libraries.

I'll go out on a limb here and assume that the targeted user population isn't the one that's most likely to keep hardware and software up-to-date. My own Mac is a mid 2011 with a 2nd gen i7 that's still powerful enough for most of what I do these days, and I'm certainly not going to update it to the latest OS it could run officially (I've seen what that did to my iPhone 4s).
You can take this as a plea to stick to using an "old" Qt version. MuseScore shouldn't contain a lot of functionality where having the latest security updates is crucial.

In reply to by rjvbertin

There is no official Qt 5.15 for M1, it's Qt 6.2+ only.

But indeed, Dorico uses a custom version of Qt (heard that in a podcast with Daniel). I believe that they got 5.15 working on M1.

I don't consider this viable for MuseScore though, because it will take a lot of time and is not that easy. I overheard that creating a full Qt build takes hours...

In reply to by cbjeukendrup

You could have a look at MacPorts (the package system Qt uses or used to use to build their Mac binaries). It'll give you binary packages (which you could redistribute).

The most expensive part in building Qt is QtWebEngine; the 5.8 version takes about 3 hours to build on my old i7 (not sure why MuseScore would need a full-fledged browser framework though). The other components you need (not a full build) should take considerably less, esp. on more modern hardware than mine. And of course it's something you do a lot less frequently than building MuseScore itself (which IIRC takes a long time too).

(FWIW: as an IDE I vastly prefer KDevelop over QtCreator, far better CMake support IMHO)

In reply to by Jojo-Schmitz

I run a self-built version (65 commits after) 3.6.2 . I've stripped the QWE dependency by commenting-out just 2 lines, and haven't noticed any differences. I haven't tried the save online feature; it might be easier to implement that via QWE but I have a hunch it should be possible without (or using a much cheaper dependency).

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?

In reply to by Marc Sabatella

FWIW, I did try looking for info on the Qt site but don't see any ARM builds at all, not even for Windows. I don't really understand the various compatibility issues - 32-bit x86 builds might be usable on Windows ARM machines? And apparently Windows 11 allows even 64-bit applications to run?

In reply to by Marc Sabatella

I run Windows 11 for ARM Insider Preview in Parallels on my ARM64 Mac. In that virtual Windows machine, I'm able to compile and run MuseScore in x86_64 mode (flawlessly; the fact that I have an ARM processor did not make any difference). So apparently, Windows does have some kind of emulation, just like Rosetta on macOS. The performance is not even that bad.

In reply to by cbjeukendrup

That makes my head spin :-). Sounds like this is saying that for Windows on ARM, people can just use x86 or x86_64 builds as appropriate. But, my understanding is the situation is not so good for Linux, there are emulators but they are slow and I gather they have be run manually. That would be most unfortunate if so. Between Raspberry Pi, Chromebooks, and people installing Linux on other ARM-based machines, there are a lot of ARM-based Linux machines out there that we wouldn't be able to support. My sense is that ARM is becoming more popular, not less.

In reply to by Marc Sabatella

FWIW, ABL has managed to create Linux AppImage builds of the master branch for ARM, both arm64 and armhf versions, and I have verified they work (well, the arm64 version anyhow). So assuming no new dependencies are introduced, this is great news for those of us concerned with making sure MuseScore continues to run on Chromebooks

In reply to by Marc Sabatella

I just checked MacPorts, they may (still) not have ARM64 binaries for Qt 5.15 but the code itself still builds apparently (apart from QWE).

That fact that Qt don't provide binaries may simply be because they consider 5.15 to be out of support (I would expect there to be ARM64 binaries for Linux, though).

Based on the little I read about Qt6 I would probably start preparing my own code, but put everything that requires modification in a separate branch to avoid multiplying conditional code blocks (except the CMake files which are probably best shared).

The ultimate decision which Qt version to target can also depend on the OS versions (and thus, MSWin & Mac hardware) you wish to continue to support. As long as you continue to target Qt5 but don't require 5.15 people who want can continue to build their own copy against older Qt5 versions.

Tantacrul and team have made the decision in terms of which operating systems will be supported and which will not be. I have done what I could to put the best possible perspective on it: Musescore 4.0 will not run on various operating systems (I did get his input before posting it). Now we at least know and can move forward. And strangely, despite my exhaustive initial analysis, the solution the team came up with was not one that I even considered, but despite probably not being a popular one with users, makes perfect sense in retrospect:

  • Despite currently developing on Qt 5.15, only target for MS 4.0 the OSes that will be compatible with Qt 6.x to avoid mid- 4.x upgrade issues, when development switches to Qt 6 in a post MuseScore 4.0 minor update.

Looking at the nightly / alpha binaries released, the writing may have already been on the wall for those desupported versions, even if “the writing” was not very public. By asking this Qt 5.15 vs Qt 6 question, I was trying to get to the “which OSes will be supported” but without asking the question directly. I eventually did get my answer.

In reply to by cbjeukendrup

Anyone interested in building MuseScore against Qt5 will probably be savvy enough to self-build Qt5.15 too if not using an environment/package manager that provides a new enough version - that just takes time. Besides, we're talking about Macs, and I see that MacPorts ships Qt 5.15.6; I have to presume HB will too.

That also means MuseScore's official binaries could be built against either of those options. (Fun fact: Qt use MacPorts to obtain the dependencies necessary for their distribution builds, or used to do so for a long time.)

Do you still have an unanswered question? Please log in first to post your question.