MuseScore is switching to Qt 6
Hello everyone!
This is an important announcement for those who contribute code to MuseScore and those who write plugins. Starting with MuseScore 4.4, we will switch from Qt 5.15.x to Qt 6.2.4.
What does this mean for developers?
The switch is happening on the master branch of our GitHub repository, which is where we are building MuseScore 4.4. To compile the master branch (and derived branches), you will now need Qt 6.2.4.
To install Qt 6.2.4, use the Qt Online Installer / MaintenanceTool. When you've arrived at the page where you can select Qt versions and components, select the "Archive" checkbox in the panel at the right under "Categories", and click "Filter". This makes Qt 6.2.4 appear in the list. Expand it, and select the following components:
- The main Qt component for your OS/compiler
- Qt 5 Compatibility Module
- From “Additional Libraries”:
- Qt Network Authorization
- Qt State Machines
After installing Qt 6.2.4, compiling on the command line will work the same as with Qt 5, except that:
- You need to update your PATH and/or QTDIR variables to point to Qt 6.2.4
- You need to pass the following option to CMake:
-DMUE_COMPILE_QT5_COMPAT=OFF(soon, when we remove support for Qt 5, that will no longer be necessary.) Update: If you are using the very latest master branch, this is indeed not necessary anymore.
Additionally, Qt 6.2.4 will appear as a Kit in Qt Creator. Select this kit, and configure it in the same way as you used to configure the Qt 5 kit. For a refresher, see Compile in Qt Creator. Set the MUE_COMPILE_QT5_COMPAT CMake option to OFF (update: if you are using the very latest master branch, the latter is not necessary anymore).
If you need to stay on Qt 5 a bit longer for some reason, you can still do so; just set MUE_COMPILE_QT5_COMPAT to ON, and put Qt 5 first in your PATH/QTDIR (when compiling on the command line) or use the Qt 5 kit (when using Qt Creator). However, this option will be removed soon.
For other branches, Qt 5.15.x remains the only supported version.
What does this mean for plugin authors?
Many existing plugins make use of QtQuick.Controls 1 and QtQuick.Dialogs 1. These modules have been deprecated for years and have been removed in Qt 6. Plugins using these modules will need to be rewritten using QtQuick.Controls 2 and/or MuseScore.UiComponents instead; otherwise, MuseScore won’t be able to detect them.
What does this mean for users?
The switch to Qt 6 will inevitably introduce some bugs, but we already found and fixed most of them. And we still have several months until MuseScore 4.4 (the first version built on Qt 6) will be released, which should be enough time to discover and resolve the remaining ones. (Want to help with testing, or just can’t wait to try the latest features? You can already download 4.4 (“master”) nightly builds at https://musescore.org/en/nightly-builds! This is at your own risk, though.)
It only has some consequences for operating system compatibility:
- On macOS, nothing will change; the oldest supported version remains macOS 10.14, which means that MuseScore can still run on 10+ years old Macs.
- On Windows, only 64-bit Windows 10 (1809 or later) and Windows 11 will be supported. This means that support for 32-bit as well as support for Windows 7 and 8 are definitively being dropped (in practice, these didn’t work well anymore anyway).
- Linux users, please check https://doc.qt.io/qt-6.2/supported-platforms.html#linux-x11 (and compare with https://doc.qt.io/qt-5/supported-platforms.html#linux-x11).
Questions?
If you have any questions, feel free to ask in the comments below or in the MuseScore Developer Discord Server.
Comments
Is it possible for plugins to 'import' depending on version used? (Esp. QtQuick.Dialogs vs. MuseScore.UiComponents)
That should enable us to make the same plugin work before and after the switch to Qt6
In reply to Is it possible for plugins… by Jojo-Schmitz
Unfortunately, not really. The only thing is that
QtQuick 2.0andQtQuick.Controls 2.0are available both in Qt 5 and Qt 6.What you can try, is something like this: https://stackoverflow.com/questions/27440425/how-to-write-conditional-i…
In reply to Unfortunately, not really… by cbjeukendrup
Wouldn't dropping the version number work (and pick the latest version available)?
Edit: it seems to work for Mu4, but not for Mu3 and Mu2, so seems rather pointless
In reply to Wouldn't dropping the… by Jojo-Schmitz
Version-less imports are only a thing since Qt 6, unfortunately.
What about Qt.labs.settings?
e.g.
Plugins/align_2.qml:11:1: module \"Qt.labs.settings\" is not installed"
In reply to What about Qt.labs.settings?… by graffesmusic
Qt.labs.platform instead seems to work.
In reply to What about Qt.labs.settings?… by graffesmusic
Strange, according to https://doc.qt.io/qt-6/qml-qt-labs-settings-settings.html it should still be available in 6.2.4.
From 6.5 onwards it is moved into QtCore.
In reply to Strange, according to https:… by jeetee
In the appimage (--appimage-extract) , i find this:
~/Documents/MuseScore4Development/squashfs-root/qml/Qt/labs/platform
libqtlabsplatformplugin.so plugins.qmltypes qmldir
(could be unrelated; i do not know Qt...)
Edit:
Qt.labs.settings can just be commented out and the plugin works ok. (plugin align.qml)
In reply to In the appimage (--appimage… by graffesmusic
Qt.labs is a namespace that has a couple of (experimental) interfaces; the platform interface is one such example; as is the settings interface.
In reply to Qt.labs is a namespace that… by jeetee
Ok, thanks for the info.
Qt.labs.settings is not in the Linux Appimage. (Qt.labs.platform is)
In this case, it seems that the plugin align.qml does not need qt.labs.settings to start with.
The plugin works when commenting out the line (in 4.4 and also in 4.2.1)
In reply to What about Qt.labs.settings?… by graffesmusic
Settings ported to plugin module (i.e. to use it is enough to import MuseScore 3.0)
https://github.com/musescore/MuseScore/blob/master/src/plugins/api/qmlp…
In reply to Settings ported to plugin… by igor.korsukov
Perfect. Thanks.
In reply to Settings ported to plugin… by igor.korsukov
When did that port happen?
In reply to When did that port happen? by Jojo-Schmitz
2 week ago
https://github.com/musescore/MuseScore/pull/21596
In reply to 2 week ago https://github… by igor.korsukov
OK, so too late to enables us to use it for plugins for all 4.x instead of the Qt one. Pity.
Why 6.2.4 and not 6.5 ?
In reply to Why 6.2.4 and not 6.5 ? by frfancha
From 6.2 to 6.5 would mean also dropping MacOS 10.14 and 10.15.
In reply to From 6.2 to 6.5 would mean… by jeetee
Is there any good reason to keep support for these historical OS versions?
MacOS 11 Big Sur runs on any MacBook released in 2013 and later, see
https://support.apple.com/en-us/103111
In reply to Is there any good reason to… by Wolfgang Glas
User Base would be a good reason.
In reply to User Base would be a good… by jeetee
Currently the biggest problem for MacOS Users is, that there is no binary for Apple Silicon.
Every MacOS Device shipped since 2021 is ARM-based and you really risk to lose all MacOS users on new devices :-/
I haven't seen MacOS 10.x users for a long time now, but you might know it better.
In reply to Currently the biggest… by Wolfgang Glas
That should be possible with Qt 6.2 already, so isn't a reason to go to 6.5
In reply to That should be possible with… by Jojo-Schmitz
That's really fine, we are all desperately waiting for amd64/Apple Silicon nightlies.
It would be really fine to have such 4.4/Qt6/MacOS-arm64 nightlies in the near future.
TIA Wolfgang
In reply to That's really fine, we are… by Wolfgang Glas
Don't get too excited about Apple Silicon builds. There will be literally no difference, at least as long as Rosetta 2 exists, which will probably be the case for the next few years.
In reply to Don't get too excited about… by cbjeukendrup
"There will be literally no difference"
What kind of difference are you referring to? A speed difference?
In reply to "There will be literally no… by Riley Sullivan
For example. In my own ARM64 builds, I don't see any speed difference on my MacBook.
Also, in terms of user experience there is no difference, because most people will have Rosetta 2 installed already anyway, and once that's done, all x86_64 apps work exactly like arm64 ones.
My point was mainly, don't get too excited about arm64 builds, since the advantages are very theoretical.
(You might wonder, if I can create ARM64 builds for my own MacBook, why don't we have ARM64 release builds? That's because we don't have a pre-built version of libsndfile that runs on both ARM64 and Intel and on macOS 10.13, and it takes some effort to set that up.)
In reply to For example. In my own ARM64… by cbjeukendrup
I've quite a lot of application running on my AppleSilicon MacBook (MS Office, gimp, inkscape LibreOffice, vlc, chrome, firefox, ...) and MuseScore is the only application, which is not ported to arm64 and would require me to install rosetta2.
I still do not get the point in supporting historical OS releases, but you might know it better :-/
In reply to I've quite a lot of… by Wolfgang Glas
To be clear, supporting historical OS releases does not interfere with supporting Apple Silicon. We can do both. The latter is simply blocked by some dependency which we need to recompile, which is tedious to do, so we're waiting until this really becomes worth the investment of time that we could also have put in solving real problems like bugs or feature requests.
(The point of supporting older OSs is that we want to support as many Macs as possible (because, Macs are expensive and many musicians can't afford to buy a new one every few years, or might use second hand Macs). Dropping 10.14 support might be fine though, since it seems like all Macs that support 10.14 can also be updated to 10.15, but I know people who still use MuseScore on Macs that can't be updated beyond 10.15.)
4.4 is already being developed when 4.3 is not released yet. How does that work?
In reply to 4.4 is already being… by TheMobiusFunction
It is a different branch of the code, master vs. 4.3.0
In reply to 4.4 is already being… by TheMobiusFunction
They are being developed a little bit "in parallel" at the moment. 4.3 is almost ready to go into the testing and stabilisation phase, so no new features are being added anymore or and no more risky changes. These go to 4.4 instead, which is still a bit further away, so there we have plenty of time to find problems.
(And of course, everything that's in 4.3 is copied to 4.4 too.)
In reply to They are being developed a… by cbjeukendrup
That'll totally ROCK
Is there anywhere the documentation about
MuseScore.UiComponents? I can't find it anywhere.In reply to Is there anywhere the… by looptailG
At first sight, many (most) plugins need some (or a lot) of change to work with 4.4
This is now Muse.UiComponents, it seems.
i agree, some documentation and guidelines would be very welcome.