While Qt 5.15 LTS release is just out, we have also been working for some time now towards the next major version of Qt. Today, we are releasing a snapshot of Qt 6.0 for the first time. While we are still very early in the release process, and far from having the feature freeze, the first snapshot is offering binaries for a limited set of platforms and focused on the essential Qt modules. Given that we are approximately six months from the planned release date for Qt 6.0, we cannot guarantee all parts of the pre-release snapshot will work as intended.
In the first snapshot, we are providing binaries for desktop platforms only. The mobile platforms and embedded Linux are being worked on; therefore, to test those you need to build from source. Qt 6.0 requires C++17 support from the compiler and we are in general focusing on fairly recently released compilers. If you want to use an older compiler, Qt 5.15 is the way to go.
The first snapshot contains the following modules:
- Qt Core
- Qt GUI
- Qt Widgets
- Qt Network
- Qt QML
- Qt Quick
- Qt Quick Controls
- Qt SVG
- Qt Network Authorization
- Qt SQL
- Qt Test
- …and a few other items
While we are missing the full content and many feature updates, providing snapshots as early as possible offers multiple benefits. First, it guarantees that the release process and infrastructure is functional. More importantly, it eases testing and evaluating the current state by you, the developers. There are still rough edges when building Qt 6 manually, having pre-built packages to verify a project against is beneficial.
To cater to the early adopters and those interested in giving feedback to development of Qt, we will continue to provide regular pre-release snapshots of Qt 6.0 – like the one released today. These will be available in the online installer under the “Preview” package category. Typically, no separate announcements are made, as these are intended to be available around every two weeks after the feature freeze (and less frequently before that).
Pre-release snapshots are found in the Preview package category of the Qt installer:
We are working towards releasing Qt 6.0 in December, with multiple important milestones along the way. By end of June, we are aiming to have the larger structural changes completed (such as the switch to a new build system, and the new graphics architecture). Also, the target platforms will be set up in the CI system. More interesting milestone from a user viewpoint is coming in the beginning of October when we aim to have the first Beta release available.
Currently, the Qt 6.0 development timeline is planned to be the following:
- Structure and platform freeze at 30th June
- Feature Freeze at 31st August
- Alpha Release at 14th September
- Beta 1 Release at 1st October
- Release Candidate at 17th November
- Final Release 1st December
These planned target dates may change along the way. If there are changes made to the plan, we’ll update those in the Qt Wiki at https://wiki.qt.io/Qt_6.0_Release.
If you are interested in following Qt development more closely, or would like to consider contributing to Qt, please subscribe to the Qt Project Development mailing list at https://lists.qt-project.org. We are always happy to see new contributors. If you feel up to it, please check https://www.qt.io/contribute-to-qt to get started. Contributing code is just one of the multiple ways you can help shape up the next major version of Qt. Providing feedback and helping others are both very beneficial and highly appreciated.
Update 25th June: We have the second snapshot out. It also contains examples. Unfortunately it is quite broken for macOS due to https://bugreports.qt.io/browse/QTBUG-85240. Fix is expected in the next snapshot.
Commenting for this post has ended.
Is the multimedia module being worked on?
Any notes on using preview version? So far qmake projects fail with being unable to find "qtmain.lib" and attempt to create cmake project finished on complains about 'Vulkan::Vulkan' target.
I was able to build with qmake adding
QMAKE_LIBS_QT_ENTRY = C:/Qt/6.0.0/msvc2019_64/lib/Qt6WinMain.lib LIBS += -lShell32Thanks! Helped for me too.
And what should we test ? What changes are included in the snapshot ?
We can help you and give you feedback, but we need to know what is the purpose of this snapshot.
We are interested in hearing feedback in general about how things worked for you. Now the first snapshot has mainly just the essential modules, so depending upon your application it may not yet be possible to test that with Qt 6.0 pre-alpha. So perhaps better to start with more basic things, if you want to try this one.
This does not really answer my question... I understand that you can't have all modules and I read your article about that, that's not the point.
My question was: What is the supposed difference between this release and the last Qt 5.15 version ? This is an important information for testing.If you say: Nothing, this should act like Qt 5.15 because it's only a test for us to deploy a Qt 6.0 version. I would be happy to know it and I would test is accordingly but testing all my projects.
But is there more ? New QML feature ? Better performances ? New cmake build system ????As far as I know it's not indicated anywhere, or not clear enough...
This is a pre-alpha snapshot, so you should not consider this as something to benchmark or draw conclusions about the final functionality of these modules. Think it more like instead of building from dev, you get a pre-build snapshot. Having a snapshot makes it convenient to test, but it does not mean things are complete.
Again this does not answer the question... I understand the principle of a pre-alpha snapshot. I don't expect to get any kind of conclusion or assumptions about the final functionalities.
Just wanted to know what should we test ? And again if the answer is just "Test with all your projects to see if it works for you" is a good answer to me.
I think they changed a lot under the hood, so the API is the same and the functionality should be the same. So we can test now if they introduced some new Bugs or they broke something completely
Will there be any changes regarding licensing? It became clear over the last few years that the Qt Company tries hard and successfully to get rid of LGPL users, first by using GPL only (if at all) for new modules, now with the bizarre market place dual licensing. What do we have to expect for Qt 6?
Tried using Qt 6 on Linux and the experience is somewhat painful. Qt5 is compiled with internal(in-source) dependencies, while Qt6 uses system dependencies, thus the user has to go and install
libxcb-xinput-dev,libxcb-xinerama0-dev, etc... one by one.Is the source available? Can't find it on http://download.qt-project.org/ so far...
Dev branch of the respective module on https://code.qt.io/cgit/ You can also check on our gerrit for latest changes currently under review.
I am looking forward for more modules, especially the QtConnectivity module. Then I can do some testing of Qt 6.
Is Qt 6 fixing the messy state of string classes in Qt? QString, QStringRef, QStringView, QLatin1String, QStringLiteral.
QString and a string view class should be enough to handle all cases. The rest is just cruft that grew in the years. All API methods should just accept a QStringView and that's it. Was this ever discussed for Qt 6?
Yes, this is being worked on as discussed on multiple occasions before. You can track the progress on our JIRA instance, for example here https://bugreports.qt.io/browse/QTBUG-84319 But there are more related items to this.
Thanks, maybe this effort could be communicated more clearly. Would make for a great post in this blog.
Agree and also on our TODO list, also for other items (like all the async items we've been working on, or networking related, ...). Expect more of these the closer we get to feature freeze...
At this point I rather they worked on the code rather than "communicated". You have as much access to the git commit history as I do or as anyone else does. It doesn't take much effort to figure it out, if you have a grasp of git workflow and blame/investigate tools.
This is some terrible misunderstanding leading to this perception. Those are all independent classes, and serve different purposes. The only real overlap is between QStringView and QStringRef, and IMHO the latter was just a stepping stone to the former, and couldn't have been removed since it became part of the public API. Of course you need a QStringView - that's what performance is all about, and you need it for interoperability with other code outside of Qt ecosystem (e.g. for zero-copy interop with native "Unicode" WINAPI.
QLatin1String is an optimization and you don't need to worry about it. You don't need to use it, and I imagine that further QString constexpr work will make it obsolete even in places where it had some positive performance impact. QStringLiteral is clearly a workaround for the missing
constexprconstructor in QString. It was a technical necessity pre-C++17. I imagine QString will get opt-in constexpr constructors when compiled in C++17 environments (unless it has already), and then you can forget about QStringLiteral & co.So calling it a "messy state" is really a mischaracterization. It irks me even though I have no stake in any of it - I'm just a user, and I'm not even a user that thinks Qt is the best thing since sliced bread. But I can understand clearly, I think, what were the technical reasons for all those constructs. They were all driven by user need and had performance implications, and you couldn't just drop them without breaking lots of products.
TL;DR: QString and QStringView is all you need anyway. Why do you worry about stuff you don't need to use, and that's only of historical significance and kept to keep old code working? Qt 6 doesn't have the QStringView support fully baked in yet, but it's being worked on if the commit history is anything to go by. Don't worry about it.
Will QT invest in the Rust Language? As QT is used alot in the embedded space. Or do you want another Disruptor company to stand up and destroy your future business?
There are companies out there that can take the Qt framework and machine translate it to Rust for a few hundred grand (USD). Those who actually need to use Qt as a native Rust solution already do that. No need for any big distruptors. You just need someone who has a good source code translation experience and has developed the tools and processes to do it. If you wanted to do a Qt release completely in Rust, you could dump a $1M in someone's pocket and you'd get it in 6 months, or so I understand. But it'd disrupt nothing - it'd be exactly the same library, just in native Rust. Sure it may help someone, but given the cost it's not something that the mere existence of "alot [of] embedded space" will make happen. Someone will have to sponsor that. At this point it's a matter of money only, since the solutions that allow such translation are available, and have been for a while. This is best done by people who do nothing but code translation, since they have the automation needed to pull it off. A manual effort is not worth it.