The Qt Company recently compared the latest Long Term Releases Qt 5.15 and Qt 6.2 of its software development platform consisting of design, development, and quality assurance applications plus various software libraries, referred to in this post as modules. This blog post, intended particularly for product and R&D leaders, summarizes the main findings of the comparison.
Comparing two major releases is never trivial, especially when there are eight years between their initial releases, the comparison highlights that there is enough feature parity for most customers to move to the Qt 6.2 LTS release., It’s important to stress that we at Qt have been laser-focused on providing Qt 6 with as much source compatibility as feasible. In addition, Qt projects can find plenty of resources in the Qt online documentation helping with the source code migration. We also offer professional services helping with the transition to Qt 6.
The Qt 6.2 Long-Term-Supported (LTS) release includes several innovative improvements allowing customers to adopt Qt as a future productivity platform, designing beautiful next-generation user experiences and scaling their product portfolio without limits. The Qt 6.2 LTS release does include also all-new functionality such as advanced 3D UX capabilities and hardware-accelerated graphics for Vulkan and Metal technologies. Qt 6.2 includes also the Qt Shader Tool module, which enables advanced graphics experiences.
Out of the 77 components that comprise the Qt 5.15 LTS release, 72 are either available in Qt 6.2 LTS out-of-the-box, the functionality has been merged into other components such as the Qt OpenGL Module, or they have been already deprecated during the lifetime of Qt 5 such as the Qt Script modules.
Five out of 50 add-on modules have not been included yet. For example, the Qt Location add-on module providing capabilities to draw maps in applications has not been used in many products using Qt. The same is true for the Qt Speech add-on module, which provides a single text-to-speech functionality. The add-on modules Qt PDF and Qt Gamepad had also only few adoptions among developers, making the justification to port them to the re-architected Qt 6 release challenging. The future of the Qt WebGL module has not been decided yet and, therefore, it is not included in the Qt 6 series. We are evaluating concepts and technologies that allow Qt applications to be operated remotely. WebGL might be a part of this in the future, but we don't want to commit to any particular technology at this point. Let us know if and how you are using any of these 5 modules for planning the future roadmap. The Qt license allows customers to embed relevant code from the Qt 5 software stack to Qt 6.
A comparison of individual features or API level is also important. We at Qt try to focus on describing the differences on feature level when there have been many changes (Check out the related posts on Qt Multimedia and the Qt Extras modules on this blog!). For example, the Qt Multimedia module will deliver on the cross-platform promise unlike Qt 5.15 reducing the development effort with Qt 6 but might miss a few capabilities. We also added some all-new functionality to the Qt Multimedia module such as rendering of subtitles. Then again, some modules such as the Qt Quick 3D module have been getting an increase of functionality required for the all-new 3D experiences such as mesh morphing and particles effects.
Moving forward, the Qt Product Management Team’s goal is to fill any gaps that may prevent projects from being successful also with Qt 6 by using a customer-centric approach. We’ll keep our radars fully powered for any change in priorities. Do get in touch through our online support channels, the open-source contribution channels, or talk directly to your customer success contact.
If you want to know the details of the comparison do check on the Qt 6.2 comparison web page web page or watch the webinar on the same topic.
Finally, this is my first blog post as a member of the Qt Community. I am referring here to both commercial as well open-source users, and it would not be complete without thanking the open-source community. Without open-source contributors, Qt would not be what it is today, irrespective of whether we are looking at Qt 5 or Qt 6.
Update: The status of the Qt WebGL module has changed and the blog post has been updated accordingly on the 7th of September.
QT Location not used often? Just how? I see so many projects using it. It is currently the main thing holding me back from migrating to QT6 in our company. It almost seems as though QT is dragging its feet here. It would be great if QT could make the next version or a new version that is based on QTQuick3d that would allow for rendering an actual 3d globe and 3d content, and also switch back to 2d if needed. Our company does robotics for which mission planning is crucial, a 3d globe with elevation data (Much like ArcGis QT) would be extremely useful for visualizing the mission and editing of waypoints in height.
Thank you for sharing. As mentioned in my blog post we look forward to feedback like this.
If it were LGPL I'd be using it too, but I had to use a WebView on a customer project years ago due that :(
We are currently upgrading our fleet management app to add QtLocation with Here navigation, also moving away from using WebView for displaying map (which was hacky, via QWebChannel). Losing QtLocation would be absolute hit...
We use Qt Location in several applications for displaying location information (a path and marker on a map). A simple OSM map view would suffice for us.
We use in our application QML Map actively which use MapBox plugin. It is essential for our app
Thanks for sharing! Noted.
Concerning the Location Module. Can you please clarify to me that it will be ported to version 6 eventually. It really sounds like you feel it is not used much and therefore is going to be depreciated. Any info you can provide is greatly appreciated.
It a bit weird that QtLocation was slashed This is the only option to have maps support in Qt application..or?
Actually that is not the case. One needs to differentiate between "showing a map" and "use routing, poi, etc features from Qt Location".
If the use-case is about integrating a "simple" map view, then there are much slimmer options to do so. There are a couple of references available, but I agree that we should document this in a better shape. (action point taken).
Moving Qt Location over to Qt 6 is a major effort, requiring almost a complete rewrite of the rendering part as well as other segments. Given that from the use-cases we know so far, a majority does not need all these features, an integration of existing map/web-views is a much leaner and slimmer solution.
Please note that there are also partner solutions by Esri, Mapbox etc which integrate nicely into Qt or even provide Qt based SDK for these use-cases.
Integrating web-views is not something I would call slim or lean. It is the least performant solution. If I wanted to build a web application I'd use a web framework not QT. Not to mention the fact that it would also prevent you from actually programming the mapview with QT. Things like:
MapquickItem, placing things on the map, Creating behavior to go to certain locations with the camera, Updating the mapview based on data gathered by the application,
All of that would be pretty much infeasible or have unacceptable performance
I agree with you. But also those are not the cases I have been referring to with "simple map view".
Even for "simple map view" there are issues, like Navigation Drawer component would not be able to be drawn on top of the WebView, or any popup or other your Qml GUI element. Native components are painted on top of what Qt does.
well, I see your point. however, webview for most of the embedded devices is not an option. An the consumers of the maps is mostly embedded solutions
It would be a real shame for Qt PDF to be discontinued: There is nothing else like it out there! What you have done is make it possible to use quality, scalable vector graphics in Qt applications. PDF is more than documents. Anything I can design in Illustrator can be shown in a Qt app, complete with font embedding! Given the innovative design of a PDF file as a multi-page image, I can use it to create layered vector images. The very limited Qt SVG support comes no where near this. I think a good reason for adoption problems is lack of advertising/information about it. The documentation is very limited as are examples. There was a very good presentation on the web about it, but the sample code is not very accessible and the presentation itself is hard to find. All in all, though, you have put some fabulous work into this release!
Thanks alot for a great comparison!
Qt Location is a dealbreaker for us. We ship 3 different business critical apps to Android, iOS and Windows desktop using commercial license.
We took the step from Qt 5.12 to 5.15 LTS at the beginning of 2021. We've invested heavily in these apps and use QML map and other features from Qt Location, and just recently we added our own model for clustering of feature points in the map (we've been expecting that this would be included by Qt for years, but as it never happened - we had to make it ourselves).
Since the release of Qt 6 a year ago, I haven't really looked into Qt6 at all until now - as I expected it to lack too much needed features previsously. But by now, I expected it to be include whatever needed, as it's a LTS release.
How did you deduce that the text-to-speech is not very used? TTS is a very important feature mainly for mobile apps and the lack of this module in the 6.2 version it makes it impossible to switch almost all of my work to the new version...
Hello Fabio! The information on how often a particular module is used is based on many touch-points we have at Qt. This includes quantitive analysis such bug reports or downloads from the market place. This also includes a lot of qualitative analysis from direct communication with the open source community and customers. The insight is never perfect and therefore any concrete project and customer names giving feedback will help us to improve our understanding. We also have noted the feedback form previous blog posts such as the Qt 6.2 alpha announcement. Thank you!
@Peter Schneider Why TQC does not run a survey like the following for collecting users' feedback? https://medium.com/flutter/what-can-we-do-better-to-improve-flutter-q2-2021-user-survey-results-1037fb8f057b
Hello! We do surveys, several per year, currently in the commercial user community. These surveys are also a source for quantitative feedback. I agree that we have some work to do to better engage with the entire Qt community. The recruitment of the Community Manager (https://www.qt.io/open-positions/community-manager-1614870577?hsLang=en) should help us to engage better with the open source community, including surveys.
We are also using TTS. Althought it would be a nice to have in Qt 6.x it is not a show stopper in contrast to Qt Location which we strictly require.
Please do not slash Qt Location. It is very useful and webview is not a viable alternative in most cases.
Snap. Gamepad support will disappear ? I just finished implementing it in a game engine... I guess there are alternatives, but having only Qt as a dependency was a big plus for that project. As or QtLocation, I can see that I'm far from being the only one who would be disappointed with that choice. I've been using it for a rental mobile application... it's still a prototype, and with that news, we'll probably just end up picking the webapp route over the native one.
@Michael Martin Moro: As mentioned in the blog post we brought all the most commonly used modules already to Qt 6.2. Qt is very widely used, so even the modules that are less frequently used do have a large number of users. We do understand that there is value also in the modules that are not yet available with Qt 6.2 and want to know better the needs and use cases. Some of these would be rather straightforward to port to Qt 6.x and some would need a major overhaul in order to fully benefit on what Qt 6 provides.
it seems The Qt company has not correct estimation of Qt usage in the Qt community, I think a good example for this is mobile app development that users widely use or want to use Qt for mobile app development but they give up because of weak support, but TQC imagine Qt not useful for mobile app development and so naturally pay less attention to mobile app development compared to other parts of Qt framework.
I use QT Location to show a sophisticated map in an open-source flight navigation app. Like many of the others, I need to map to be performant on low-end devices, so the MapBoxGL plugin for QT Location was my first choice. After some experiments, I doubt that a map in an embedded WebView will be as snappy and performant.
Qt Speech is not currently used, but I had plans to use it in one of the next versions to pass traffic warnings to the pilot, who is not always looking at the display.
Thank you for your input!
The pdf module was introduced very recently. It arrived only in version 5.15. We thought it was a useful tool. We planned to use it in version 6 when it would probably become "mature".
@Domenico Zucchetti: Due to limited adoption of Qt PDF (in Qt 5), we are still studying whether to offer this as add-on module for Qt 6.x in the future.
It strikes me as a surprise to hear that QtLocation is considered to have low usage. I have always thought that nowadays every second app has a map-view with some kind of waypoints on it. I agree that geocoding, navigation, etc.. can be left to custom solutions or commercial providers, because it also needs more complicated backend. But it would be really nice to have a possibility to draw maps (OSM, MapBox, etc) and custom objects on it. This will make a solid base for custom sulutions like routing, etc. About WebView - I hope you were not joking :)
I remember that even MapItemView+MapQuickItem is not performant enough to draw more than a few hundred points smoothly. This lead to the new MapObjectView initative. It was a good way forward but unfortunately stayed in the 'lab' status and as far as I remember it was very difficult to extend it (something about subclassing QGeoMapObjectPrivate and QQSGMapObject) to make custom map objects. So in the end I found a solution by extending private class QDeclarativeGeoMapItemBase and if you don't use too many vertices in your item (QML Rectangle with round corners, aka circle, uses massive number of vertices because anti-aliasing) then it performs nicely with even more than one thousand map objects, also on mobile devices. And it only uses QSG-prefixed classes.
My strong suggestion would be to support at least basic map drawing and make it possible to create custom map objects on C++ side (by exposing currently private QQSGMapObject or something similar).
I'm missing the differences in QtNetwork: QNetworkConfigurationManager is removed to get info if network is reachable there's now a new Class QNetworkInformation For my apps where I'm always checking online state it's some work to remove QNetworkConfigurationManager and use QNetworkInformation instead. It's deprecated in 5.15, but I cannot prepare for 6.2 because QNetworkInformation is new in Qt 6. This should be mentioned, so users know, that there's something to watch
Hey, The QNetworkConfigurationManager removal has been documented in the module update documentation: https://doc.qt.io/qt-6/network-changes-qt6.html
But you are right, that in 6.0 we have not had a direct replacement, which has been introduced at a later stage with a new (and of course better :) ) API.
We have tried to keep API changes to a minimum, but for some cases we needed to take this step to be able to mitigate those cases for the next decade to come with a stable API.
It took me about half an hour to upgrade our app at work to Qt6. It was really only small bits like missing QVariant includes and some minor enum changes 👀👍
yep - the new Class is much better and I appreciate the work was done to check reachability better
It's sad that QtGamepad won't be in Qt6. It prevents us to move to Qt6.
It's pretty easy to port QtGamepad to Qt 6 as it's a pretty small module (in fact I already have). It's more that I didn't want to release it in its current form to Qt 6 (because then it's stuck like that for the lifetime of Qt 6). Instead I wanted to provide a more generic API for input devices, and then have a convivence API specifically for gamepads built on top of that. I got way too much feedback in bug reports and suggestions that were as such: "my input device that is totally not a gamepad doesn't work with QtGamepad". So if we wait and release a more complete API you could use whatever input devices you want by mapping them programmatically.
I could probably release a port of QtGamepad that works with Qt 6 on Github or something, but as far as something that is officially supported, I think we should aim for a more comprehensive API instead.
The Qt Location module is so important for us as the others and without it impossible for us to migrate to Qt6.
Unfortunately, The Qt Company does not listen to all Qt users, it's so important that TQC conducts a survey every quarter to figure out from users feedback which part of the Qt framework can be improved.
I hope to see more attention from TQC to the users' feedback.
Maybe most QtLocation users are LGPL users, and if they don't have enough paying commercial customers that decision comes as logical for them.
Unfortunately yes, it seems TQC generally to ignores developers that use open source licenses.
As we all know Qt is great, so we are here to have an even better framework.
QLocation was mostly used in our QML application, with Map, MapView, MapItemView, and MapQuickItem being the primary components. In addition, Location and map for most modern applications is a necessity.
On the other hand we can see other big competitors such as Flutter or RN, which focus to have a convenient API for developers. As a result I think the QLocation is so important module for developers and webview is'nt a good idea in realworld applications.
Qt must work on holding developers and provide new features that will make it easier for new developers to join the Qt.Therefore, removing QLocation would be a bad idea for community.
I hope TQC pay attention to community demand.
It is nice to see that Qt 6.2 brings improvements in the 3D and 2D rendering. Nevertheless, I have to say that there is little or no mention to improvements oriented to desktop applications. This is a pity I may say. Companies and developers using Qt/QML/QtQuick to develop custom made GUI are missing a some simple components like a TreeView on QtQuick(Qt6) for example . As we know the QtQuick controls 1 are deprecated now on Qt 6, but as I said there are everyday-use components like TreeView that are not present or like TableView that are not yet well documented or feature completed in Qt6.2 LTS. There is a new TreeView component available on Qt Marketplace, but I find this very strange, even users with a Qt Professional License will need to pay extra for this component, which by the way is also not well documented. From this kind of advertisements you are giving the impression that you are not so interested on desktop applications anymore. I encourage the Qt Company to be more consistent in this aspects. If I knew this last year when I started a new desktop project using Qt I would probably use another framework.
I also use the Location and QTextToSpeech modules in my application. It would be really great to maintain them in Qt 6!
We use the QT Location in our application with Map components and osm plugin. The main features of this application is to display a network with MapItemView and MapPolyline overlayed on a city map. We've invested heavily in the developpement of the underlying C++ model. It would be really important to maintain this module in Qt 6.
We where just waiting for QT Location to migrate to the QT6 for 3 of our main projects. We already suffer from the missed TreeView, without QT Location we will sadly quit the Great QT Framework. When are you going to decide for the go nogo please ?
The Text to speech technology has made important quality progress these last years and is still making some progress. I have seen (heard) stunning results recently. The chance is that it will become more and more a standard. This would be a pity to give up the related module.
The linked document claims "Qt Windows Extras has been moved into the Qt Core offering and does not require a standalone module", yet a blog post a couple of weeks ago explicitly said that all functionality in this module has in fact been removed entirely in Qt 6.2 - https://www.qt.io/blog/qt-extras-modules-in-qt-6
It makes me concerned that I can't trust the rest of the information here - what else is not actually in 6.2 but is planned for later versions?
Thank you, Richard, for pointing this out! I talked to Tor Arne, the writer of the Qt Extras blog post, and he confirmed to me that we could clarify better. We will change the wording in the comparison table for the Qt Extras to "<Module name" has been moved into other modules and does not require a standalone module." Because not everything has been moved to Qt Core, but also some stuff to other places.
I find your response extremely disturbing.
That statement is simply wrong. It's not true. Almost every single class and function from the QtWinExtras module has been completely removed and has no replacement in Qt 6.2.
For example: https://doc.qt.io/qt-5/qwintaskbarbutton.html
Only some(?) conversions between Qt and native handles was moved elsewhere.
Some Mac Extras functionality has also been lost in 6.2.
So what else is gone from other modules? When you make one obviously false statement it indicates that I cannot trust anything else in the document.
I am aware of several QTBUGs to bring back some/most of the functionality in some future version of Qt, but at the moment these have no target versions and obviously will not be in Qt 6.2
Hello Richard! I'm sorry that you feel this way. The best way to get a detail insight on what changed with the Qt Extras is indeed in the related blog post here: https://www.qt.io/blog/qt-extras-modules-in-qt-6. We were limited in terms of space in the comparison table to describe the details and, therefore, like for Qt Multimedia, we published dedicated blog posts on these modules for more clarity. Apologies for the having temporarily misleading information on the comparison page. When comparing 77 modules, few misinterpretations slipped into the comparison. These should be now corrected.
Means Neptune 3 UI will be discontinued for >=Qt 6.2, because is uses the Qt Location module?https://github.com/qtproject/qt-apps-neptune3-ui/blob/dev/apps/com.pelagicore.map/views/ICMapView.qml
I've been using Qt Speech in a commercial product on both MacOS and Windows since that module was first introduced in Qt5. It is used to give dynamic verbal instructions to a user while they are making adjustments to hardware while they may be several feet away from their PC and not able to see the screen. This has worked great and is used in several languages including German, Japanese and Chinese. Not having this support in Qt6 is a deal-blocker for me.
Your use-case sounds pretty familiar to a project I have been doing as well in my spare time :)
For Qt Speech there are two considerations. Initially, the idea was to not only handle the text to speech, but also the speech recognition aspect. This was before other successful solutions had been created by other vendors and where the developers needed to shift its design approach (either integrate other solutions via backends, or have dedicated integrations for each due to very different designs).
Secondly, you might recognize that the module itself does have required changes to build with/against Qt 6 if TTS is your use-case https://codereview.qt-project.org/q/project:qt/qtspeech
But at this point, it is not included in the default distribution of Qt, because it's not ready and there is no strong agreement where Qt Speech should be heading to or if it is generally required. Maybe you can also reach out to us to discuss some further details of your project.
Let me know who at Qt I should talk to and I'll be happy to provide more detailed feedback. FYI we have been commercial license users of Qt since Qt4.
I assume by "build with/against Qt6" means that we would need to build the Qt libraries from source on our own in order to get this functionality? That again is pretty much a deal-breaker. Building Qt libraries is a real PITA vs using the pre-compiled ones and adds an extra layer of configuration, hassle, testing, worry etc. that we have all of the build parameters correct for each platform.
Easiest is to reach out to your sales rep in that case. You might also just send me an email to continue, (first.lastname@qt.io).
About the compilation, please note that Qt is built modular and we have been investing a lot into strengthening that. So you are able to download and use the pre-built binaries, and then only build Qt Speech via "cmake, ninja/make" for your target. That eliminates a lot of the initial setup as well as compilation time.
Let me get this straight: that fact that this bug https://bugreports.qt.io/browse/QTBUG-85260 is marked as done in 6.2.0 beta 4 means that we'll be able to use QtLocation as it is in Qt 5.15.3? Or does it mean that it's done because QtLocation is dropped from Qt 6? I filed that bug more than an year ago and since I'm an open source user I don't have access to 5.15.3 and I really got my hopes up this week when I saw the bug is marked as fixed in 6.2.0. And by the way, +1 to the list of projects that really use QtLocation (not sure how many more you need to understand that this module is really used and really needed)
LOL. xD
Where is the webinar ? I'm going round in circles. The original broadcast was at 7AM GMT today. But I want the re-broadcast for 17:00GMT today. Original invite zoom does not work now, webinar page on qt.io website does not contains the topic of this blog. The link to webinar at bottom of this blog at this time does not go to the webinar. But but to the list of all webinars (which currently does not contain the topic of this blog)
Thanks for pointing this out! The URL for the webinar has been swapped from the "upcoming webinars" page to the "on-demand" webinars page now.
Where is the webinar? Can you tell me more about it. Contact Info https://m8winpro.com/tieng-ruoi-link/ Really nice post!
Hello! You'll find the webinar recording here: https://resources.qt.io/on-demand/qt-6-2-lts-vs-qt-5-15-the-big-feature-parity-comparison-on-demand-webinar
no more QXmlSchemaValidator
We use Qt Location with OpenStreeMap or MapBox in our commercial applications that run on Windows, Mac, Android and iOS. It is an essential part or our product and as other have said, there is no viable alternative.
Its better to have QtSpeech with functionality as in Qt 5, then do not have it it all...