Lars Knoll

Technical vision for Qt 6

Published Wednesday August 7th, 2019
132 Comments on Technical vision for Qt 6
Posted in Biz Circuit & Dev Loop, Dev Loop, Qt

7 years ago, Qt 5 was released. Since then, a lot of things have changed in the world around us, and it is now time to define a vision for a new major version. This blog post captures the most important points that can and should define Qt 6.

Qt 6 will be a continuation of what we have been doing in the Qt 5 series and should as such not be disruptive to our users. But a new major version will give us a higher degree of freedom to implement new features, functionality and better support the requirements of today and tomorrow than we currently can within the Qt 5 series. As described in more detail below, Qt 6 will aim for a large degree of compatibility with the Qt 5 series. We are also still working on new versions of Qt 5, and we’re aiming to bring some of the features that will define Qt 6 in a slightly reduced form to Qt 5.14 and Qt 5.15 LTS. With the feature freeze of Qt 5.14, more R&D focus will shift towards Qt 6, and we’re aiming to have Qt 6.0 ready for a first release by the end of 2020. Before we dive into all the things that will be new, let’s also remember some of the core values of Qt for our users, to define the things we don’t want to change.

What makes Qt valuable to our users?

Qt is a horizontal product that is being used in many different markets. The core values Qt has for our customers and users are:

  1. Its cross-platform nature, allowing users to deploy their applications to all desktop, mobile and embedded platforms using one technology and from a single code base
  2. Its scalability from low-end, single-purpose devices to high-end complex desktop applications or connected system
  3. World-class APIs and tools and documentation, simplifying the creation of applications and devices
  4. Maintainability, stability, and compatibility, allowing to maintain large code bases with minimal effort
  5. A large developer ecosystem with more than 1 million users

A new version of Qt needs to adjust our product to new market demands while keeping the 5 items above at the heart of what we’re doing.

The desktop market is at the root of our offering and is a strong and important market for Qt. It is where most of our users get the first contact with Qt and forms the basis of our tooling. Keeping it healthy and growing is a pre-requirement to be able to grow also in other markets.

Embedded and connected devices are where we have our biggest growth. Touch screens are coming to an exponentially increasing number of devices, but there is strong pressure on the price point of the hardware for these devices. Low-end chipsets, microcontrollers, combined with small to medium-sized touch screens will be used everywhere. Most of those devices will have relatively simple functionality but require polished and smooth user interfaces. Large volumes of such devices will be created, and we need to ensure we can target that space with our offering to be able to live up our scalability promise.

At the same time, user interfaces at the high end of the device spectrum will continue to increase in complexity, containing thousands of different screens and many applications. Merging 2D and 3D elements into one user interface will be common, as will be the usage of augmented and virtual reality.

Elements of artificial intelligence will be more commonly used in applications and devices, and we will need to have easy ways to integrate with those.

The strong growth in the number of connected devices being created as well as much higher requirements on user experience makes it more important for us to focus on world-class tooling to simplify the creation of applications and devices. Integrating UX designers into the development workflow is one of our goals, but there will be many other areas where we need to try to simplify the lives of our users.

Qt 6 will be a new major version for Qt. The main goal with such a new major version is to prepare Qt for the requirements coming in 2020 and beyond, clean up our codebase and make it easier to maintain. As such the focus will be on those items that require architectural changes within Qt and cannot be done without breaking some level of compatibility with Qt 5.x.

Below are some of the key changes we need to make in Qt to make it fit for the next years to come.

Next-generation QML

QML and Qt Quick have been the main technologies fueling our growth over the last years. The intuitive ways of creating User Interfaces using those technologies are a unique selling point of our offering.

But QML, as it was created for Qt 5, has some quirks and limitations. This, in turn, means that there is the potential for significant enhancements, that we are planning to implement with Qt 6. The main changes planned here are:

Introduce strong typing. Weak typing makes it hard for our users to apply large changes to their codebases. A strong type system allows for IDEs and other tools to support our users in this task and dramatically ease the maintenance. Also, we will be able to generate much better-performing code and reduce overhead.

Make JavaScript an optional feature of QML. Having a full JavaScript engine when using QML can complicate things and is an overhead especially when targeting low-end hardware such as microcontrollers. It is however extremely useful in many use cases.

Remove QML versioning. By simplifying certain lookup rules in QML and changing the way context properties work, we can remove the need for versioning in QML. This, in turn, will lead to large simplifications in the QML engine, greatly simplify our workload of maintaining Qt Quick and simplify usage of QML and Qt Quick for our users

Remove the duplication of data structures between QObject and QML
Currently, quite some data structures are duplicated between our meta-object system and QML, degrading startup performance and increasing memory usage. By unifying those data structures, we will be able to cut away most of that overhead.

Avoid runtime generated data structures. This relates to the point before, where many of those duplicated data structures are currently being generated at runtime. It should be perfectly possible to generate most of them at compile time.

Support compiling QML to efficient C++ and native code. With strong typing and simpler lookup rules we can convert QML to efficient C++ and native code, significantly increasing runtime performance

Support hiding implementation details. ‘Private’ methods and properties have been a long-time requirement to be able to hide data and functionality in QML components

Better tooling integration. Our current code model for QML is often incomplete, making refactoring, and detection of errors at compile time difficult to impossible. With the above changes, it should be possible to offer compile-time diagnostics that can compete with C++, as well as much improved refactoring support.

Next-generation graphics

A lot of things have changed in the graphics area since we did Qt 5.0, leading to us having to do significant changes to our graphics stack to stay competitive.

With Qt 5, we used OpenGL as the unified API for 3D graphics. Since then a host of new APIs have been defined. Vulkan is the designated successor of OpenGL on Linux, Apple is pushing for Metal, and Microsoft has Direct 3D. This means that Qt will in the future have to seamlessly work with all those APIs. To make that possible a new layer abstracting the graphics APIs (like QPA for the platform integration) called the Rendering Hardware Interface (RHI) has to be defined. We will need to base all our rendering infrastructure (QPainter, the Qt Quick Scenegraph, and our 3D support) on top of that layer.

The set of different graphics APIs also leads to us having to support different shading languages. The Qt Shader Tools module will help us to cross-compile shaders both at compile and at runtime.

3D is playing a more and more important role, and our current offering doesn’t have a unified solution for creating UIs that contain both 2D and 3D elements. Integrating QML with content from Qt 3D or 3D Studio is currently cumbersome and causes some performance overhead. In addition, it is impossible to sync animations and transitions on a frame by frame level between 2D and 3D content.

The new integration of 3D content with Qt Quick is aiming to solve this problem. In this case, a full new renderer will allow rendering 2D and 3D content together and support arbitrary nesting between the two. This will turn QML into our UI definition language for 3D UIs and remove the need for the UIP format. We will provide a technology preview of the ‘new’ Qt Quick with 3D support already with Qt 5.14, more information will come in a separate blog post.

Finally, the new graphics stack needs to be supported by a decent pipeline for graphical assets, that allows preparing those at compile time for the target hardware and use cases in question. Convert PNG files to compressed textures, compile many of them into texture atlases, convert shaders and meshes into optimized binary formats and more.

We also aim to bring a unified theming/styling engine to Qt 6, which will allow us to get a native look & feel on Desktop and mobile platforms to both Qt Widgets and Qt Quick.

Unified and consistent tooling

Our graphical tooling to create User interfaces has been split into two with Qt 3D Studio and Qt Design Studio. Additionally, Qt 3D Studio is slightly disconnected from the rest of Qt leading to quite some duplicated efforts.

We will unify those by merging the required functionality from Qt 3D Studio back into Design Studio. Design Studio shares a lot of code and the application/plugin framework with Qt Creator allowing for a great design experience and giving us the tools to bridge the gap between designers and developers.

The Design tooling also needs good integration with content creation tools such as Photoshop, Sketch, Illustrator, Maya, 3D Max, and others.

The developer tooling needs a lot of focus and attention so that we can offer the best in class support for C++, QML, and Python. A unified tooling offering also implies that developers can easily use the design functionality from within Qt Creator and that UX designers can benefit from features of the developer tooling such as compiling a project or on-device testing.

QMake as the build system used in Qt 5 has lots of quirks and limitations. For Qt 6, we aim to use CMake as a standard 3rd party build system to build Qt itself. CMake is by far the most widely used build system in the C++ world, and better integration with it is sorely needed. We will continue to support our users on QMake, but not develop it further or use it to build the Qt framework itself.

Enhancing our C++ APIs

C++ has changed a lot over the last years. While we had to base Qt 5.0 on C++98, we can now rely on C++17 for Qt 6. This implies that C++ offers a lot more functionality out of the box that wasn’t available when we did Qt 5. Our goal with Qt 6 has to be to better integrate with this functionality, without losing backward compatibility.

For Qt 6, we aim to make some of the functionality introduced with QML and Qt Quick available from C++. We work towards introducing a new property system for QObject and related classes, integrate the binding engine from QML into the core of Qt and make it available from C++. The new property system and the binding engine will lead to a significant reduction in runtime overhead and memory consumption for bindings and make them accessible for all parts of Qt, not only Qt Quick.

Language support

With Qt 5.12, we introduced support for Python, and we also added the browser as a new platform through Qt for WebAssembly. Keeping and further extending that cross-platform focus will be an important part of the Qt 6 series after 6.0 has been released.

Compatibility with Qt 5 and incremental improvements

Compatibility with older versions is extremely important and is a major requirement when we develop Qt 6. There are billions of lines of code written using our framework and any incompatible change we do will thus have a cost for our users. Furthermore, the more work the change to Qt 6 requires from our users the slower the adoption will be, which leads to more cost on our side to maintain the last version of Qt 5.

As such, we should aim to avoid breaking Qt in a way that triggers compile-time or runtime errors in our users’ codebase. If we must break compatibility, a compile-time error is preferable over a silent breakage at runtime (as those are much harder to detect).

While we do need to remove certain deprecated parts of Qt, we need to ensure that our users have the functionality they require. That implies that key functionality, such as Qt Widgets and other parts used by a large portion of our users, will, of course, stay available.

We are planning for many incremental improvements to our core classes and functionality that we could not do in the Qt 5 series. The aim is to keep full source compatibility, but as we can break binary compatibility with Qt 6, we can do quite a lot of cleanups and improvements that couldn’t be done within Qt 5.

Nevertheless, we need to move forward, and some house cleaning is required with Qt 6. We will remove most functionality (functions, classes or modules) that have been deprecated in Qt 5. This house cleaning will help free up our developers’ time in the longer term and allow us to have more focus on the maintained and current codebase.

Porting away from those deprecated parts does however need to be as simple as possible and our users can ideally do this incrementally using Qt 5.15 LTS. Our goal should be that Qt 6 is compatible enough with Qt 5.15 LTS so that one can easily maintain a large code base that can compile against both versions at the same time.

Marketplace & technical product structure

In addition to improving the Qt framework and tools, we aim to create a new marketplace for components and development tools. The marketplace will be focused on our direct users developing and designing applications and embedded devices, not targeted at consumers. As such it will be a central rallying point for the Qt ecosystem. It will give 3rd parties a place to publish their additions to Qt, allowing for both free and paid content.

Qt has been growing a lot over the last years, to the point where delivering a new version of it is a major undertaking. With Qt 6 there is an opportunity to restructure our product offering and have a smaller core product that contains the essential frameworks and tooling. We will use the market place to deliver our add-on frameworks and tools, not as a tightly coupled bundle with the core Qt product. This will give us additional flexibility on when and how we deliver things and allows us to decouple release schedules for some add-ons.

Give us your feedback and get involved

The technical vision will evolve further until the first release of Qt 6. While I believe that this document captures many of the most important points for the next version of Qt it is certainly not complete. If you have any further ideas, please get involved in the development of Qt 6 and discussions around it through Qt’s open governance model.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Biz Circuit & Dev Loop, Dev Loop, Qt


NIkolai Marchenko says:

But where is QML/Desktop on your priority list? It’s been seriously lacking the last couple years with some widgets literally being unusable in desktop interfaces without any alternative provided (hello combobox). Also, are therre any plans to modernise C++/Widgets?

Lars Knoll Lars Knoll says:

I do mention a unified theming engine for Widgets/Quick Controls, to solve issues for Quick on the desktop. There are some ideas how to modernise C++/Widgets, but no conclusions yet. Of course any changes there have to be done carefully to not break all the billions of lines of code written against those APIs.

toni says:

Since contracts, metaclasses, most of networking and reflections was deferred to C++2x (x >= 3) maybe huge refactor will be moved to Qt 7.

Benjamin Buch says:

Another important point is native Unicode support in C++. As long as the language standard itself does not cover important points like this, Qt still needs many of its own developments.

We’ve always had things like std::vector, new ones are std::variant and std::any. For QString, however, there is no suitable replacement.

A lot is planned, I am confident that a big refactoring can take place at some point, but definitely not before Qt 7. Besides, that would definitely be an API break.

Toni says:

Yeah, but it can proof both interfaces, Qt like and STL like, also I would like a standard way implementation to metaclasses / reflection to replace qmake step. But i’ll not be in near future 🙂

Thiago Macieira says:

We’ve been paying attention to SG-7 (Compile time programming, previously known as Reflection) and our hope is that eventually it could replace moc in most cases.

But C++ reflection can’t parse XML, so there’s no replacement for uic or rcc. Build tools are good. moc is only one aspect of it.

Marco says:

There is the embedded proposal which could replace rcc.

Michal Lazo says:


I think that Qt should add some official support for modules as for example npm, NuGet
For example qpm(
with real support in qt creator and building tools

It will be also nice to move some parts of official qt modules to this packages.
with proper maintenance with backward support.

Nils says:

I think a lot of the things will make many people very happy (away with the JavaScript ;-).

However there’s always the damocles sword of the Qt Company taking away the L from LGPL from some module’s licensing options.

Can you elaborate on the business plans for Qt6, too?

Jan Niklas Hasse says:

> This means that Qt will in the future have to seamlessly work with all those APIs. To make that possible a new layer abstracting the graphics APIs (like QPA for the platform integration) called the Rendering Hardware Interface (RHI) has to be defined. We will need to base all our rendering infrastructure (QPainter, the Qt Quick Scenegraph, and our 3D support) on top of that layer.

This is a huge waste of time. Just continue to use OpenGL + GLSL and use the various libraries which translate it to Vulkan (e.g. Zink), Metal (MoltenGL) and Direct3D (ANGLE).

Laszlo Agocs Laszlo Agocs says:

You need to consider however that figuring out and working around the peculiarities and quirks of the various translation layers, pulling in and maintaining all these 3rd party dependencies, dealing with the potential lack of support for the more exotic platforms, potentially incompatible licenses, etc. can all end up being a waste of time as well.

Going directly, with minimal and lean abstractions in the middle, to whatever is the best supported graphics API on a given platform or device will pay off in the long run.

(Also, Zink is a Mesa Gallium driver, MoltenGL is a commercial product. None of these are suitable for inclusion in Qt. Maintaining ANGLE as a 3rd party dependency in the Qt 5 series has been known to be a hassle. The more we can simplify the stack, the better.)

Yotam says:

WebGPU should be standardized around the same time. It has cross-platform buy-in (Apple, Google, Microsoft, Mozilla) and implementations callable from native code (dawn and mozilla’s).

Laszlo Agocs Laszlo Agocs says:

Building on something like Dawn would come with the usual downsides: managing more external dependencies and potentially losing support for less common yet important platforms, thus invalidating the Qt cross-platform story by basing the Qt graphics stack on a library that does not itself rely on Qt’s platform abstractions (by skipping all the OS and windowing system glue QtCore and QPA in QtGui provides).

Incidentally, there are many similarities between the APIs of WebGPU (as it stands now) and QRhi (the graphics abstraction layer mentioned in the post). However, in Qt’s case this is all private API for the time being, i.e. an internal enabler for Qt Quick and the upcoming 3D features, so not something directly used by application developers. If it gets opened up at some point however, we should indeed consider if it makes sense to make it as close as possible to WebGPU (assuming the concepts and APIs are still close enough at that point).

Neil Trevett says:

Another option is to simply move from OpenGL/GLSL to Vulkan/GLSL. Vulkan is natively available almost everywhere: Windows, Linux, Android, Embedded etc. etc. Its multi-threaded dispatch may give you a performance lift if you are CPU-bound. There is also a safety critical version of Vulkan in development at Khronos.

For Apple devices you can use MoltenVK to run Vulkan over Metal. It is open source (Apache 2.0) and royalty-free. It is already being used in shipping production apps, and Khronos is working hard to enable layered implementations of Vulkan to be officially conformant in the near future.

Maybe Qt already tried MoltenVK? It has matured significantly over the last few months – and the Vulkan Portability group at Khronos would love to hear any feedback you have to help us fill in any gaps/issues you may have found.

Laszlo Agocs Laszlo Agocs says:

True, MoltenVK is an option as well, assuming one has it installed and has a Qt build configured appropriately. It seemed to work pretty well with the few Qt Quick apps I tried (on macOS, have not yet played with iOS much yet).

In Qt 5.14, where the first early preview of the new OpenGL-independent Qt Quick renderering stack is planned to ship, Vulkan via MoltenVK is already listed among the platforms:

Thiago Macieira says:

Note that linking to Apache 2.0-licensed code removes the option of using GPLv2. That removes compatibility with existing codebases that aren’t “or later”.

Mousavi says:

Agree with Neil Trevett +1👍🏻
so there is not need to efforts on special graphics api

Kezi says:

Why don’t you just use Vulkan for everything?
It runs on everything but mac, and on mac with moltenvk, that is already production ready.
Having to learn another abstraction layer with its quirks doesn’t sound that appealing

Laszlo Agocs Laszlo Agocs says:

Remember though that the “abstraction layer” mentioned in the post is an internal detail, not a public API, for the time being, and so has no relevance to application developers.

If one wishes to integrate their own native Vulkan rendering code into a Qt Quick application, that’s fine. Just make sure Qt Quick is rendering via Vulkan as well. The story in this respect is not different from what it is today with OpenGL.

kla says:

Well, similar decision was made for Qt 5.0: Use OpenGL everywhere.
However, as you already know, Qt 5 supports various hardware/software backends now.
For Windows support, it is very important to support Direct3D because it is related with several parts of Windows APIs, for instance, multimedia.
I don’t know macOS/Metal much, I guess the situation of macOS/Metal is similar with Windows/Direct3D.
Unless those big enterprises give up their own APIs, it cannot be a good decision to ignore platform-dependent APIs and support platform-neutral API only.

Oleksandr Palamar says:

Actually, this. Using Qt Quick over Angle helped me to integrate it into a game on Source Engine – Black Mesa. Qt Quick can become real alternative to Scaleform and other popular UI frameworks inside of the game development industry.

Talkless says:

If basis of Qt6 will be C++17, any thoughts about integrating Coroutines with signals/slots? Making work with networking easier, maybe something like:
QNetworkReply* reply = co_await nam->get(…);
// here reply is finished()’ed, ready to get error or data.

Dimiter 'malkia' Stanev says:

AFAIK, coroutines are not in the C++ standard. I mean, I wish we had them, but I can’t find anything confirming so (maybe missed something while searching

hilefoks says:

Support for coroutines would be nice. However, coroutines is a C++20 feature, not C++17.

Talkless says:

Oh sorry, yes, it’s C++20, I’ve mixed them up.

Louis says:


Thanks for this article, very interesting!

A few questions – you might now have an answer so soon:

1) Regarding compatibility and QML improvements such as strong typing, do you already have an idea of how fine (or not) this can be integrated within existing QML applications?

2) About deprecated modules that will be removed, will QtQuickControls 1.0 be removed?

3) I would be curious to know about the new styling module, it looks like a new stylesheet cross QtWidgets/QML? Stylesheets were great and dynamic but it was from my point of view not really efficient for “custom” items, when we want to have special shapes or behaviors. On the other side, QML allows to do many things with the freedom it provides, but in term of styling, Material styles etc. always seemed a bit to light for the needs – and even though extending it was a possibility (not very easy), I frequently found myself doing a bad thing: mixing behaviors in JS and styling.

4) Does it mean C++17 will be the minimum version for Qt6?

5) About the graphical layer, OpenGL was a bit hellish to handle, because even though we are not supposed to take care of this as developers, there was frequently issues:
– depending on the Intel HD Graphics version (when no dedicated GPU was available), the graphical memory is really an issue when we open multiple QtQuickViews in QtWidget tabs (we quickly run out of video memory, leading to crashes – QTBUG-66292)
– RDP management with Angle is not really nice because to support 24 bits, we have to mess a bit with QSurfaceFormat
– RDP again, on Win7 it has to be forced to “software” to support all kind of GPU
– “desktop” mode sometimes makes glitches/crash depending on the GPU so I generally have to force to “angle”.
I don’t know how you will be able to make RHI handle all that but I hope this will help.

Good luck for all this,

Thiago Macieira says:

On C++17 (I’m not qualified to answer any of the others): We’d like to require that as the core language minimum, but we live in the real world. For a Qt 6.0 released at the end of 2020, the minimum compiler versions are probably what exist today, if not something like 6 months ago. That means we need to figure out what they supported then or support today, setting that as a baseline.

Rest assured that we will not make it unduly difficult for our users. You will not need a bleeding edge 2020 compiler. At the same time, we want to start writing nicer code, like using fold expressions, template deduction guides, etc. There are even small things like assured copy elision that make quite a difference in the codebase.

Ville Voutilainen says:

Yeah, we need to look at a reasonable common set of C++17 functionality that we deem okay for Qt 6, without necessarily allowing all of it. This depends to some extent on what the compilers can do, but in some ways it’s like migrating to C++11 from C++03, we want to allow some of it, but don’t want to go all-in if compilers haven’t caught up yet. Luckily, C++17 is fairly small language-extension-wise.

Glauco says:

I hope that with Qt 6 the Qt Company will modernise its product offering. Now, Qt is sold like we were still in the 90’s. The “one price fits all” for “enterprise” customers is completely insane. Qt for mobile failed to attract purchasers because, at the time of the offering, Qt for mobile was more an unfinished project than a polished product. Qt for WebAssembly should not be treated as Qt for mobile was. Another point to consider is a price difference between individuals and organisations (like JetBrains does). I hope the aforementioned marketplace will be used by the Qt company too so that Qt can be offered for targeted audiences in a more streamlined and customisable way (Web, Mobile, Desktop, IOT, …).

Konstantin says:

Web browser and mobile platforms are the most widespread now and in future. So it is excellently driven with QML technology. Good job.

Firat says:

It was about time!

I ‘m interested in QML section mostly. QML has polishing ability to continuously rendering to given size. For 3-4 years of experience with QML on Mobile development, I ‘ve encountered many of times that polishing stops to reach actual size in Android and low-end Android supported devices. Not many for iOS though.

In the end, I reported bugs any issue that I ‘ve encounter but most of the time, didn’t get valuable return from qt support.

Then, Flutter came out. As building UI it was similar to QML (by just looking the code), hierarchical tree and labeled parameters…. But with one small and awesome difference. setState() function… which allows when tree will be rendered manually. Even if the Dart VM is slow, this surely optimized our code and able to deliver high performance app. If there is no interaction? No need for rendering…. That is vital and developer friendly. So no more animations falls short during opening in cross platform, no half sized boxes because of simply main threaded stalled with a long task or during booting of application for low-end device.

So is there any plan for such performance improvements on rendering? What is more in performance improvements other than just compiling the code to native? What will be the pipeline?

Chris Adams says:

Your comment about setState() is interesting – just so I understand fully, are you saying: the advantage of Flutter is that while the various data may change in the application (e.g. properties of objects etc), the actual UI isn’t redrawn until setState() is called on a particular widget subtree (and when that method is called, the rendering engine renders what the state specifies); whereas in QML due to the way bindings currently work, any change to any property will immediately cause all dependent bindings to be re-evaluated even if such changes are “transient”, and for the built-in QtQuick types (like Rectangle etc) any change to properties with visual effect (e.g. geometry, position, color, etc) will trigger QQuickItem::update() (marking it needing re-render by scenegraph), without being able to control which sets of updates will precisely finish before the threaded render loop preempts evaluation, and there’s no easy way to tell the engine “redraw this hierarchy of items now, using these sets of property values”?

A few points on this (my personal opinion only, of course):

a) If you implement your own QQuickItem-derived types, you can manage when to allow ::update() calls via an external state machine, if that behaviour is required. Or alternatively, implement your own setState() analogue which sets properties and calls ::update(). But this doesn’t help you if you want to use the built-in QtQuick types while still manually controlling render checkpoints (although I would argue that that is a benefit of QtQuick: you don’t have to remember when to call ::update(), or manually manage some complex state machine; instead it’s done automatically for you based on when the visual properties change due to property binding re-evaluations).

b) Manual polish() can be dangerous due to polish loops (e.g. layout concerns related to content width / elision / etc) and the “implicit” polish order being defined by when you call polish() for the items (i.e. posting an event to the event loop).

c) I guess you could use QQuickRenderControl instead, but obviously that requires even more work to get right.

d) But I completely agree that one of most important (if not the single most important) performance improvement opportunity for QML would be to implement “pull” rather than “push” binding evaluation (with per-property dirty flags, and idle-time evaluation metering).

As an aside, I’m also interested whether any syntax improvements will be made to the QML language (e.g. the fact that id attributes look like object properties rather than attributes of the component, is one clear candidate for improvement, IMO).

Yurii Nakonechnyi says:

Still waiting for accelerated QtWidgets (like QML) – to continue writing code in an imperative style (in c++) with all graphical features of QML 🙂 Thanks for your work, guys.

stefaan himpe says:

easier QML 2-way binding?

Jerome Godbout says:

That would be soo needed, I’m tired to rewrite a 2 way binding with a container accessor and a converter everywhere I have work. Access and writing to a list of map value and converter for deg to/from rad for example.

A built-in 2 way that doesn’t do binding loop would be awesome, this is painful to write properly and often end up with some quirk (Yes I’m looking at you Qml ComboBox!).

Add my vote for this!

Jason says:

1. Well I would think/hope that for Qt6 Mobile is a a first-tier platform. It’s in line with “Embedded and connected devices are where we have our biggest growth.”. Many single board computers now offer the choice of plain linux or Android. However for iOS, which is moving away from Objective-C to the more modern Swift, Qt cannot (yet? ever?) use Swift. There are notable deficiencies of Qt on these platform (Push notifications for example) which aren’t cutting edge. Mobile has had those for 13 years and there’s no Qt API for them.

2. I lament QtQuick Controls every time I use them, v1 or v2. I wish they were like their QWidget counterparts. There should be only one core UI library going forward.

3. Web. While Qt continues to stay local, and there’s a few not-ready-for-prime-time web efforts (WebGL, WebAssembly) the future is web. QML should be a web technology like React or Angular. And then the upsell is you can get the web crowd onto devices without the need for a Web server/browser combo and all that overhead. There are far more web developers out there than embedded. QMLWeb is a good start.

3b. I would also like to shout out to Wt, which is Qt 4 imagined as a proper web platform. ( ) If you can do what they do but with Qt5/6 then you’d have a winner right there. The difference is they leverage the browser’s ability to use local resources (CPU, mem) rather than streaming WebGL calls. You get fast local execution and minimal server overhead – the best of both worlds.

3c. You need something to compete with Electron and those other Web-app in WebKit frameworks. Qt can supersede them all.

dhaumann says:

Since you are talking about improved tooling, it would be nice to have a language server protocol implementation for QML that text editors that implement LSP (VS Code, Kate, Atom, …) also easily support code completion, code navigation etc. Even Qt Creator could use it itself.

Peter says:

1. Will there be license changes?

2. Will there be deprecation in the platform support, e.g. will keep supporting both X11 and Wayland for Linux?

David Porter says:

I didn’t see any mention of graphing and visualization enhancements. Are there plans for that?

Pierre says:

As a small developer, I wouldn’t object to a ~$500/yr licensing fee just to continue getting all the rights I now have for free (not covered by the $6,500 license). I want to insure you continue staying in business, and enhance the product even more.

Dimiter 'malkia' Stanev says:

What’s the story behind modern multi-monitor support, and docking? It’s usually the norm for a game studio to have artists using multiple monitors of different sizes, and good docking support is a must there. Something no less than what Visual Studio has to offer.

While we made our efforts to make something (internal) matching it, it’s still riddled with issues, possibly mainly due to our limited knowledge of Qt internals, and how to do this proper. Maybe also the fact, that we are building this on top of the public API, not internal (or, just our excuse that we can’t excel and do it that way).

There have been some improvements to have floating dock into another dock, but it needs more. Also the “center” widget thing is bit from the past. Just my thoughts.

Never used QtQuick/QML and also makes me wonder – can these be easily embeddable and also docked like the rest? Can we write dock layouts, and restore them everywhere? Also can the serialization part go through our custom text format, so that we can have a bit more internal control? E.g. these are real issues we are fighting day an day.

A bit more on the C++17 – what’s the story with the integration with the rest of the std::? Being able to control the memory allocation is another thing we would like do be able to do. On Windows, it’s not always easy to replace safely the memory manager, and we’ve been relying on std::pmr:: for the rest of our code base (also not very easy path). qMalloc/qFree are deprecated AFAIK, but would love to see if they can be re-enabled. We build Qt ourselves, use the DLL version, so maybe there could be way to enable it back.

Other than that, thanks for the great project! Gotta tell you though, every 2nd programmer wants to convince us to move into Dear IMGUI land.

Uwe Kindler says:

You can try this Advanced Docking System for Qt:

Frank Dana says:

+1 on the QApplication layout being a dinosaur. Unlike most of Qt where things are exposed via well-documented public APIs, the structure of the QApplication’s QMainWindow and (in particular) its DockWidgetAreas has the feel of dark voodoo.

QMainWindow::setCorner is just terrible, things like dock dropzone size and snapping distance are completely unconfigurable, and the whole thing is very resistant to any attempts to make it work in a manner different from the outdated UI template it was designed to facilitate.

Szyk Cech says:

I give you some moral credits for good ideas:
+ The same classes for C++ and QML
+ Most (?) QML functionality available from C++
+ CMake as build system
+ Real C++ properties
+ Qt shop

You have one bad point:
– You insist on QML: this is classic “vendor lock”. Apparently you have problem with identity as C++ library provider. If you realy have to turn to the scripts you can use some “standard” language (instead still reinvent the whell. Yes I talk about: Qt Script, Qt Quick1, Qt Quick2; Do you want develop Qt Quick 3 now?). Python probably is best choice, then. But I don’t believe that complicated tools (eg. 3D design tool) written in scripting language will be workable – no way!.

Tom says:

Main components of Blender are written in Python, btw.

Shi Yan says:

this is very exciting.

my wish list:

1. The installer framework has a command line only mode. This lets me deploy the latest qt to a remote server with only ssh access.

2. an official dark theme, the one used by QtCreator looks good.

Hm says:

Thanks for the nice overview of the planned future way for Qt 6!

Here is some feedback:

++> We also aim to bring a unified theming/styling engine to Qt 6, which will allow us to get a native look & feel on Desktop and mobile platforms to both Qt Widgets and Qt Quick.

1.) It would be great if not only the styling (colors, …) changes, but also the theme adapts to the platform specifics (different ways of navigation between views for instance) as far as possible (see Felgo or Flutter). If this is too complex then at least an iOS (and macOS) style for Qml should be shipped with Qt 6.

2.) In the past we found that Qml is not very well suited for desktop systems. Thus we created a layer of abstraction which dynamically creates Qml or Qt Widgets depending on the platform. This turned out to be extremely useful because we only have to modify the C++ code and all the UI is automatically handled. I think a similar approach is used by Flutter. Maybe this layer of abstraction is something worth considering for Qt 6 as well.

3.) Key based navigation (tab, scroll, …) in Qml is very cumbersome despite the recent improvements.

++> Marketplace & technical product structure

I like the idea but Qt should not end up as a splattered product where you have to buy/download each component from the store.

++> Attract mobile developers

1.) Qt 6/Qt Creator should provide easier access to the Qt system for newbies. For instance, Qt Creator could provide wizards for Android and iOS (maybe other platforms too) which completely setup a project. With “completely” I mean that everything (signing, packaging options, …) can be easily defined without having to study the documentation in dozens of places and without playing around with variables in the project file.

2.) The planned marketplace should provide a plugin for Admob which is a major factor for many mobile developers – maybe even complete Google Firebase support (

3.) The Qt Purchasing module should support subscriptions in a convenient way which are essential for most freemium models. The module should hide the complexities of the app stores from the Qt developer (such as subscription validation).

4.) File access in Android, and especially in iOS has evolved in the last years:

4.1) On Android, Qt should provide means for write access on SD cards if possible (

4.2) Android pickers could be integrated more transparently (i.e. the file dialog opens an Android picker; the save dialog shows a nice Android styled save dialog).

4.3) Recent iOS versions got much better file sharing support (using document handlers). Qt should transparently support read/write access using the iOS document handlers.

Chris says:

As you mentioned it, Felgo supports all these items Qt does not support right now already. You can see the API overview here:

OkApp says:

Very useful indeed!

online says:

It would be nice if we could get rid of moc and make it far easier for bindings to Qt to work (I’m looking at Rust mainly). Integrating Rust with C++ is a nightmare.

Dithermaster says:

It’s great that you’ve got a solution for graphics APIs, but what about unifying GPU compute across platforms? Anything for that? It would be nice to be able to code to a single compute language (for example, OpenCL C/C++) and have it run across all supported platforms (perhaps via SPIR-V).

Laszlo Agocs Laszlo Agocs says:

That work also covers compute to a large degree. Not OpenCL or CUDA, though. Rather, we have compute shader (and image and buffer load/store) support in all the RHI backends (so OpenGL (4.3, ES 3.1), Vulkan, Metal, and D3D11). The shading language is Vulkan-flavor GLSL, like for graphics. This is all internal however, not exposed to applications. It remains to be seen how/when this gets utilized. But the enablers are all there.

Julian Michailov says:

I love Qt for fore more the 10 years. Qt was and … still /?/ is a leading C++ framework. I believe there other c++ developers who will share my opinion as well but since 5.X – Qt definitely IS MORE – QML then Qt – C++ . I can give many examples where straightforward is said: “Currently there is no C++ API”… plus Most of examples are in QML.
So what kind of C++ framework is that when there is NO c++ interface only QML.
On other side – Qt was OpenGL – way to go – Maya and so many other applications are built on Qt because of that … now middle-ware like bgfx make their way ahead because Qt is falling behind – even books changing their example from Qt to other OpenGL middleware frameworks. Other example of this is Qt3D – it hard to switch from Qt/C++/OpenGL to Qt/QML/Qt3D – so what is the purpose then when just before 3-5 years almost 70%of OpenGL apps/demos/examples were written in Qt/c++/OpenGL /
I see is mentioned from Lars that “ QML and Qt Quick have been the main technologies fueling our growth over the last years” –and wish financial success because Qt deserve that , but on other side very “unnatural” to use QML for more complicated desktop applications.
Related with this is the point that – QML is not multiplatform script language – backed with the power of Qt / I believe PyQt had this intention/ which you can adobe and solve almost all needs / e.g. Python, Lua, AngelScript/ – NO – still have to be C++ compiler etc. – so the benefit is only how we can describe ui in the descriptive fashion as similar to css and to connected with signals.
Plus when I hear the Qt Widgets will not actively develop only maintained – it is look like as a signal that Qt goes in other direction but not C++.
Is that true?
I understand that devices and car market has potential but hybrid – cloud/on premise distributed applications as well.
Just to describe my point – Windows/Linux/Android/Web OpenGL application with “eye candy gui” – bgfx/ImGui/Lua/TreeJS vs. Qt/QML/Qt3D – who will have advantage ….. and the point which I want to underline – on Cloud-Linux –on premise – Windows- and clients as Android and Mac – that is the place where I saw Qt shine and which looks more and more abandoned.
I believe that harder transition to QML in the expense of c++ will make more people leave Qt then new to adobe the framework.
So here is my feedback in one sentence: Qt is C++ and let’s continue to be C++ framework.

Arturas Matonis says:

Yes, the last true Qt release was 4.8 and it was released by Nokia. As experienced embedded systems engineer i can say that Qt project is going in wrong direction and is only matter of time of forking.

@Arturas: Sorry to hear that you do not think the functionality offered by Qt 5 is beneficial. However, there seems to be many others who do see good things in Qt 5. The amount of downloads and number of users have grown tremendously since Qt 4 days, so I think we are doing something right.

Arturas Matonis says:

The real Qt 5 improvements was the merges of Lighthouse project and Android port. After that you directed almost all efforts into QtQuick/QML, forgetting that Qt in the first place has always been a crossplatform C++ GUI library.

Julian Michailov says:

@Tuuka I want to say that since Qt 4. Qt moved away from positions in which Qt dominated
– OpenGL – frameworks as SDL, GLFW and BGFX with/without ImGui – more and more getting Qt 3D position;
– Core c++ stuff as Containers, Strings, Maths – more and more Boost/STL c++ transitions not the opposite way which was before- not portable STL’s to Qt.
– SQL XML Databases processing/integration – Java, Python, C# – took everything away for Desktop
-WebKit days from KDE – gone…:-(
-Application scripting – far away are QtSript days.
-Multimedia – video, audio … Qt is hard to be considered …
-and Qt Crown Jewell – 2D Graphics / remember – thousands of chips demo and the whole QGraphicsScene approach /- is replaced with QML sliding pages and bulky “speed” gauges.
I remember Qt started long ago in 2D graphics doing something like AGG – Anti-Grain Geometry – and up Qt 4 combination of good preprocess work/ QObject – Signal and Slots/ + solid C++ as containers etc. + “2D eye candy” – was the combination which no C++ developer can resist. Now is QML. It is hard to convince project development -why QML is better vs. JavaScript/JQuery 2D/GUI libs -/commercial or not/. Thanks God- the Widgets Qt still exist – and in the Cloud and AI world and GPU lib wars – is a solid C++/OpenGL tool.

Tham says:

I buy the idea of using qml to develop mobile like apps, qml works better for that kind of ui, but I never like to use qml for desktop apps.For me, biggest problem of qml are

1. Qt company want to use it as a replacement for everything, including QWidget and QGraphicsScene, but I never even find out the components offer by QtQuick are good enough to replace them.
2. Qt company refuse to put more efforts into QWidget and QGraphicsScene even qml never mature enough to replace them

selcuk caglar says:

Qt 6 is a big new. Actually qml need a package manager, We should qml packages install via (package-manager) install (package). Setting qt enviroment is very hard.
And Please make mobile more attractive. We should use qml like flutter or xamarin.

ParalaX says:

Those are nice updates 🙂

I might add a suggestion: I’m a hardware guy, but I like to do the hardware, the code on the micro, and the GUI. At the moment, I use QtCreator with bare metal plugin to develop the code on the micro.
And frankly: it’s the best IDE out there!

However, It would be great to get more support on this features:
– Real time variables debug
– RTOS awareness
– More user friendly way of configuring the tools (e.g. openocd)
– Better support on the clang side

Once it’s done, there even might be some very nice integration, like a “debug pipe” where the microcontroller send data to a GUI application, which would help debug when the hardware communication channel is down, for instance.

And finally, Qt on uController on top of, let’s say, FreeRTOS would be the dream!

Pau Garcia Quiles says:

Porting to NuttX is probably easier, as it’s alread POSIX and very much BSD-alike

3e says:

What will happen to QtScript – I guess it will be gone. However anything close to that, I mean scripting language with possibility to embed debugger open doors wide open for high-tech industry applications where from my perspective it will be quite common use case.

Having such functionality really open doors to shine for Qt as a excellent platform for SCADA platforms especially for Industry 4.0. Where we can easily create sophisticated data pumps, dashboards, product validators and analyzers and custom functionality almost on demand.

Seamless connection with OPC US is not sufficient – this is only base platform for such applications.

It is already possible to very easily mimic top SCADA platforms with much better support for databases, custom interfaces and data visualisation and communication possibilities. Maybe my perspective is niche use case – but I see huge potential for Qt in Automation as I already have successfully implement such custom systems for last decade.

Leaving option for embedding any script interpreter already does most of the job IMHO.

Jason says:

I have to admit, I do AI and I don’t really see Qt doing anything useful there. Maybe you can facilitate on-device models for forward propagation only, in which case being able to create the network and initialize the weights from leading kits (SciKit, TownsorFlow/Keras) and then perform the forward evaluation. But I think it’s limited, There’s no point to AI an studio.

Though I often wanted better OpenCV integration (officially supported cv::Mat conversions and sharing) as well as a hardware-accelerated vector (Eigen?) library.

DavidB says:

I would like to see Google’s Protocol Buffers added to QObjects, maybe their Properties could have a macro for exposing this to GPB . That is in addition to READ,WRITE,INVOKE, there is a GPB flag that will atomically expose it to some the GPB code generator.

Cloud service features would be nice,although not sure what could be done here as every cloud service seems to have their own API, and their C++ bindings seems to be a step child to JavaScript, Java, and Python. Would it not be nice to use Google’s Firebase authentication out of the box with your Qt/QML application.

I’d like to see Qt adopted more by AI and Machine Learning platforms that are all the rage.

I’ve been with Qt for a long time, ever since version 2.0, and look forward to seeing what is in store with version 6, and 7

Johannes Lochmann says:

… and while at it add production ready support for grpc!

Jason says:

“I’d like to see Qt adopted more by AI and Machine Learning platforms that are all the rage.”

Why? There’s no need for it. Tensorflow is going web-based, to reach the widest possible audience. To pull that back in to Qt land would be a step in the wrong direction. Also, Cloud GPU is the way of the future, so that your laptop doesn’t need a NVIDIA card (I’m looking at you Apple) The only thing a AI user and Qt would have in common is forward propagation.

DavidB says:

Clouds computing is not ideal for embedded space. Can you envision an autonomous car coping with internet latency or even dependent on an internet connection. The web stuff is fine if your sorting cat videos or playing games, but trying to do anything in close to Real Time in the field demands C++

Stefan says:

I would love to see an easy multi threading support for QML.

Alex says:

A good starting point will be segregating rendering out of Gui. Offline drawing does not imply Gui all the time…

AR says:

Integrating linuxdeployqt into official Qt would be appreciated.

Offering a 32-bit x86 Linux official installer (like before) would also be good to easily setup x86 build machines with latest Qt version.

I would love some macdeployqt command line option(s) to directly create a signed .pkg installer.

QTableWidget improvement : do not scroll table when a new cell is programmatically selected and this cell is visible yet (or maybe I’m not using QTableWidget the right way).

Keep it up, Qt is for me the best cross-platform GUI application developing framework on the market !

@AR: Deployment in all platforms is definitely an area that could be improved. It would not even need Qt 6, but of course a new major version is also a good opportunity to do this type of things. However, first we want to especially focus into things that can only be done with a major version so that these are all complete for the .0 release. More things can and will be offered with .x releases.

Thiago Macieira says:

32-bit Linux has gone the way of the dodo. It has security implications due to the smaller number of bits available for address randomisation. It has way too few registers available for efficient coding. And no CPU capable of running Qt has sold by either Intel or AMD in the past 6 years lacking 64-bit support.

So, no, 32-bit x86 installers are not coming back.

Luca Carlon says:

My opinion is that QML is hardly lacking type safety. Type safety was one of the greatest reasons to go with Qt instead of going with other technologies. Since QML was born, this advantage has disappeared almost completely. So +1 for type safety in QML.
Another relevant problem for me is having to deal with two considerably different worlds: C++ and QML/JS. Even C++ objects must be wrapped in QObject’s to be used in QML/JS. In my company we had to build automations to speed up development when reading QML properties from C++ and calling JS functions from C++ or wrapping C++ structures in QObject’s. In other frameworks, it is simpler to manipulate UI elements: for instance in Flex/AS, Android, iOS… References to UI elements can be retrieved in AS, Java/Kotlin, Obj-C/Swift and the elements can be manipulated in those languages freely (and type-safely). In Qt, C++ definitions of elements do not seem to be public. And also it is not possible to inherit from them to specialize an element. If you are considering making JS optional, maybe something is about to change…
Thanks for sharing your new ideas.

vladimir says:

I love all the graphics classes in Qt =)
Very glad to know about their improvement. Thanks to Qt developers!

But I don’t understand why many QPainter methods take a pointer to QPointF. QPointF uses qreal, which is double on the desktop. Graphics cards use float for rendering. It looks like there are extra costs to convert double to float.

And is it possible to allocate memory for graphic primitives directly on the graphics card? Not to transmit data every frame. For example, so done in SKIA.

Laszlo Agocs Laszlo Agocs says:

QPainter’s primary backend is a pure software one (the so-called raster paint engine), so double is not necessarily an issue there. It only becomes awkward when interfacing with an API like OpenGL. This has been taken into account in some of the more recent classes like QVector2/3/4D and QMatrix4x4. Those are all floats internally. QPointF and others being qreal ( == double by default) internally is indeed annoying sometimes, but not a dealbreaker in practice.

Shaodong says:

I wish the RHI layer could be directly called in the Qt3D module, so that people could customize the render aspect more easily. For example, I like the layered design of bs::framework(
Keep up the good work!

Robert says:

Will it be possible to use QtQuick purely with C++? Derive from QML components in C++ to adjust them to my needs?

Lars Knoll Lars Knoll says:

I’m not promising anything for the moment, but we are looking into this as an option.

Uwe says:

According to the blog post it does not look like migrating Qt/Widgets to a more modern graphic stack or opening Qt/Quick for C++ is part of the Qt6 vision. Obviously a solution has to come from somewhere else.

QSkinny ( ) is AFAIK the only effort, that has been made towards Quick/C++ so far. In case you are interested in the state of this project: there will be a presentation at the Qt World Summit.

Karol Polak says:

I think that rethinking the concept of item models would be a good idea. These models have been created many years ago for use with QtWidgets and then naturally been taken over by QtQuick. While the use of models with widgets was based on roles, using them with QtQuick is more convenient with models having QObjects as elements. This means that the properties of a QObject are written directly and no setData method is used, it does not automatically send dataChanged signal, which makes cooperation with e.g. SortFilterProxyModel difficult. QObjects can be stored in many models and can change their properties extern without knowing that this QtObject is stored in some item model. It is currently necessary to trigger dataChanged to update of proxy models. This can be achieved in a generic way through some workarounds now, but maybe it is possible to develop some alternative concept of item models that would be better suited for use with QtQuick, or be more flexible and modern.

In addition, I think it would be good if in Qt 6 were no restrictions on template classes that inherit from QObject. Something similar to what does, but available directly in Qt for example with moc or in any other better way.

Vlad says:

It absolutely does not make sense to base item models on QObject elements just because of properties. QObject is a “heavy” object which takes lots of memory, while item models can have millions of items. Btw. many people are misusing the concept of item models in Qt, they are using it like a (tree-like or table-like) database for storing data in QVariants. But this is completely wrong idea, it leads to extremely messy codebase, which is not type-safe. The correct way is to implement your business logic data structures completely without Qt item models. And then in another tier subclassing QAbstractItemModel (QAbstractTableModel etc.) only as an adapter to this real data structure which would allow viewing the data in Qt views such as QListView or QTreeView.

Karol Polak says:

It is clear that QtObject is a heavy object. But this is not important for all applications, because not all applications are using millions of items, or not have to create an instance of QObject for all elements at once). We are talking about ease of use in some use cases and not about over optimization. Once again, I emphasize that I do not mean using QtWidgets (QListView or QTreeView) but the models used with QtQuick Views (for example ListView). And there is no doubt that QObjects are better and easier to use because of the ability to easily use their properties in complex bindings and automatic updating of content in all places where they are used in UI. Roles in delegates are not as flexible as using of properties of QObjects. Especially if in a delegate for some model we want to present some properties from related objects (often not directly related to our objects) and additionally these foreign properties have an impact on sorting or filtering in our list. Current mechanisms do not allow us to do this without hacks. I am not saying that the use of QObjects in item models is the only right way, but you definitely can’t say that it is categorically wrong. If you think this is a completely wrong way, how about that used this type of model containing QObjects in his application presented at the Qt World Summit and perhaps also in the Qt Conference App itself. There is no one perfect implementation path. It depends on the particular case. It would be good if Qt 6 supports various implementation options.

Vlad says:

How about ? I think that your suggestion of using QObject as a model item would only lead to crappy coding style. Btw. If you really insist on having QObjects as items, you can always make your own data model using a collection of QObjects and then add a QAbstractItemModel tier as an adapter. It is not that difficult.

Vladyslav Stelmakhovskyi says:

+ manipulating with model’s data from non-gui thread

Vlad says:

I am still a user of QtWidgets. The reason is that QML and QtQuick still lack maturity IMO, many widgets are missing. Btw. I am a pixel peeping person and still do not like how the text and some icons are rendered on the desktop, many times it just feels blurry. However I like the idea of convergence between widgets and QtQuick controls. One way would be to allow handling of QtWidgets in QML (there is a library for this somewhere), but I would like QtWidgets ta take something from QtQuick as well. I mean the more concept of composability, i.e. composing widgets or more primitive ones (e.g. frameless text box composed next to an icon inside a rounded frame) as it can be done in QtQuick. Nowadays we have only fullfledged QtWidgets (e.g. text box with a frame) and no layer of primitives below it. Unless we implement the custom rendering of the widget, which is so difficult to do properly… Also widget layouting system feels very dated and clumsy. This would also deserve fully reworking. You mentioned styling/theming of widgets, which is very much needed in modern UI. And once implemented, please depreciate stylesheets, they are just horrible as they are.

But I have another idea which I hope could be done someday because I think you have all the bolts and nuts ready after creating Qt for Python… My dream are “hybrid applications”, i.e. Qt/C++ application frame with customized Python based widgets which can be created/handled dynamically at runtime by calling Python code from C++. This would mean interfacing Python and C++ somehow, allowing to pass parent/child pointers and connecting signals and slots. I do not know it is possible in general, I hope it is. It would allow extremely dynamic and customizable applications by just adding Python modules to it.

Karol Polak says:

The only control that is really missing in QtQuick is TreeView. You can vote here: All the others are there, or it is not difficult to implement them yourself.

Q says:

This is funny thing about TreeView because Qt missing stable TreeView for long time and instead of making basic control, there are many hardly ever used components and classes have been developed.

Johannes Lochmann says:

So how about a calendar widget? A TimeEdit? A DateTimeEdit? A TableView that can be used for other operations than just mere displaying of a rectangular grid with data? A look at the big component vendors should be enough to see that QuickControls2 is severely lacking modern convenience components…

Juan says:

I see a lot of people using this comments section as a feature wishlist. Why don’t you guys create a feature wishlist page for Qt6 that counts votes for logged in users? Something like:

Suggestions and votes for new features can already be done via

Konstantin says:

It looks that it does not work practically because most voted features are not implemented for years

beeka says:

I too would like more info about any proposed licence changes? We use LGPL where I work as the inconvenience of complying with the licence is less than the $100k per year for 20 developers to occasionally develop desktop applications. Developing an IOS for start-up use is currently not practical with $5k per year. Hopefully further modularisation of Qt6 will allow the possibility to statically link for a lot less (~10% for the only commercial feature desired).

If you intend to move more towards GPL/Commercial only licenses, an indication of this would be helpful.

OkApp says:

Have a look at the startup plan:

Steven Blackburn says:

The company I work for is large, so wouldn’t qualify, and is not against paying sometimes large sums for software licenses but it has to be good value. IIRC, the terms say that all development has to be done under the commercial agreement (i.e. can’t spend two years developing a product under LGPL then start paying $500 per developer per month… forever). Unless you are a business like KDAB, which seems built around Qt, both the terms and the cost are not practical. Paying for perpetual licenses with optional maintenance stops the SDK owner holding the application developer to ransom.

There are no details on start-up prices… even at a “generous” $50 a month package, I would need to be confident I would get money back… to develop at $50 a month + $99 a year for apple developer fees and -30% apple commission would require sales of $1,500 in the first year… and to keep paying the $50 a month even as sales drop off. A modest target for the next flappy bird or Facebook but quite a some of the simpler / novelty app ideas I have. I am familiar with Qt so would be keen to use it for mobile apps but other frameworks might be a better investment (e.g. flutter).

Some indication of a licensing roadmap to go along with the interesting technical vision outlined above, would be most useful: even a “no changes planned” would be enough.

Andrey says:

After some years make finally stable TreeView component in Controls 2😁

Aramis Romero says:

Is there any plan to make QtMultimedia a not platform dependent module

HGH says:

So, you are not getting rid of MOC just yet?

Ville Voutilainen says:

We are not getting rid of MOC just yet. We would need a fairly powerful standardized reflection mechanism for that, and that’s still in the pipeline, but making decent progress. There’s no knowing when bits of it will be landing, though.

HGH says:

Do you have any recent blogs, articles, progress reports on the topic. The last time I read something about that was years ago.

Would the new C++ mechanisms such as Meta Classes, coroutines, etc. future futures etc. help?

Nejat says:

Getting rid of moc in Qt 6 would be a good idea. Using something like

Olivier says:

Why not doing like things work in real world for licence and price. You can let people buy one version of Qt. For example one developer can buy Qt 6.0 for 1500$ and pay nothing after. He pays only if he wants update or support. And he can ue Qt 6.0 forever.

For now the price is per month (or year), and it is not clear what happens if you stop a project and go on it 1year later, u stop paying licence and you continue after…

Carl says:

It is clear read the license…. If I recall correctly, 6 months after your last payment you no longer have a license. This is in effect a “lease” or “rental”

Olivier says:

So if i understand well, to keep commercial licence on a project that can stop or continue later, we have to pay only one month every 6 months ? It should be easier to pay only once for a version.

Jakob Lettenbichler says:

“We will remove most functionality (functions, classes or modules) that have been deprecated in Qt 5.”

Getting rid of old code is okay, but I would _really_ appreciate it to have a list of the stuff you want to kick asap (nice would be a migration guide for these elements as well).
We are planning to build some major internal dependencies on Qt XmlPatterns, since there is no alternative to it in the Qt world, but dare not to start that project, since no one was able to tell us whether this will be kicked with Qt6 or what we should use instead (We asked the forum and the mailing list).

Due to discontinued features we had to keep Qt4(!) alive internally even for new projets until a few months ago (existing projects we will be needing to support decades from now with Qt4 due to the long product cycles), due to missing features in Qt5.x compared to Qt4. By now we finally have been able to find replacements outside the Qt world and tools written by us.

Repeating that is something we really want to avoid…

Vlad says:

I think it is simple. Just do not use what is now marked as ‘deprecated’.

Jakob Lettenbichler says:

Hm, I would do that if there would be an alternative to it.
Don’t get me wrong, there are many things of Qt that are outdated and should be gotten rid of sooner than later, but typically that only makes sense if there is a proper replacement for it.
Without the Xml Patterns module (which handles Xml templates and such) there is nothing that is coming close to it in Qt. The XmlStreamReader and Writer tools we are already using, are in the Core module but lack similar features yet.

TTGil says:

I think it’s worth considering a serialization system that “just works” thanks to MOC (or some newer C++ language mechanisms). Any QObject-derived class would inherently know how to serialize itself, allow for specialized behavior via function overrides, support versioning, and separate the serialization code from the “wire format” so the object can be saved to platform-neural compressed binary data, json, etc. Currently it’s possible to serialize to/from json, but for each class, a lot of code needs to be written, and there’s lots of room for errors. I think it would be pretty great if there was a reliable Qt way to save and load app data. For most situations, a QObject should just know how to save and load itself and its children.

Also, generating default implementations for property declarations as part of the macro would be great. Our C++ code would be much more concise without all that extra boilerplate code.

Jason says:

I believe that QtCreator will generate the boilerplate for you. It’s not a macro. but it should also never change much (but the macro can’t ever change) so you’ll have it there in the source if you want.

TTGil says:

Yeah, it’s not great. For a single property, you have to press option+enter, select the menu item to generate the missing implementations, which get dumped inline, so then you have to click on each one, hit option+enter, then move the implemention to the cpp file. If you have an object with, say, 15 properties, this generates a ton of boilerplate code. Obj-C/Swift/pretty much any modern language I can think of allows you to declare object properties and synthesize getters and setters in one line, and not have that boilerplate kicking around unless you override it. This is a fairly minor quibble, but it would be nice to address in a modernized Qt6. It goes together with the idea of built-in serialization. I think Qt should be more “opinionated” when it comes to these things because of the presence of MOC; properties, versioning, and serialization being pretty common meta-object concerns.

Sylv says:

What do you mean by “The new integration of 3D content with Qt Quick”? What will be the place of Qt3D within the futur Qt6 ?
Do you plan to have another API to manage 3D content ?

Thib says:

Good point.
Any info on that matter ?

Hernan Martinez says:

Two-way binding in Qt Quick 🙏 Thank you

Oleg says:

There is a some sort of “two-way binding” in Qt Quick – property aliases:

d3fault says:

-Introduce strong typing
-Make JavaScript an optional feature of QML
-Support compiling QML to efficient C++ and native code

Amazing. As a C++ developer, the Qt6 QML offering is looking mighty tasty.

-Qt Shader Tools

Interesting. Sad that it’s sorta duplicated effort, but I think you’re right that a *minimal* abstraction… of the abstractions… is the way to go.


N/A says:

Are there no plans to make it easier to use Qt from languages that aren’t C, C++, or Python? Involving an entire browser isn’t a solution.

Plenty of languages don’t even have Qt5 bindings.

stlcours says:

There are still 14000 bugs in the list of QTBUG. Please first eliminer about 10000 bugs and then start Qt6. I found that Qt prefer developing the new functionalites, not eliminering the bugs, this is not a good( or perfect) idea!!! Even there are many P2 bugs.

Qt is good enough for 90%(or 95%) of peoples. We don’t need so many breaking changes, and needing less bugs of Qt! Please well consider what is told by me. Thanks.

Alex says:

Yes, I couldn’t agree more!
I wish Qt developers would dedicate even a week to the core Qt functionality, which is UI for C++ applications, instead of useless toys like QML. My bug on poor high DPI handling on Windows has been opened and seen no activity for over a year now; apparently, UI bugs are low priority for a framework that is predominantly used for UI. Which is not to say Qt does not offer other functionality like file and network I/O, but that functionality can be easily had in a number of other well-established library, the same cannot be said for cross-platform UI.

I wish Qt Company would pat more attention to the one niche where they have the least competitors and are the most needed.

Mihail Naydenov says:

As GraphicsView + background OpenGL user, if I am to transition from 5.6, I currently use, I will absolutely need access to the graphics API. I don’t use/need 3D, but I need low level texture access (texture2D and friends; also mip-map control) and a shading language for screen space effects. Thanks.

Elie Zedeck says:

I think Qt is interesting, a lot of works has been put in there. But I think, a lot of these works, especially for the GUI creation, has not see enough thoughts and influence from the existing market. Look at Flutter now, the web development domain, true instant reloading everywhere you turn; now, where is Qt? For many years, Qt was strong in GUI, but apparently it is now largely surpassed by many younger open-source projects. There is no real integration between your C++ code and the GUI, it is essentially broken, Qt Creator, Qt Designer Studio, QML Live, etc… they are all fundamentally broken. Why Flutter, VueJS, React, … are all popular, because that’s what developers want for the last 5 years now, and Qt still hasn’t caught-up.

Second, Qt could have been much more popular than Flutter by now, but the licensing it way too prohibitive. It is just not possible for a newbie to get enough information to effectively be productive with Qt other than to get information from the Qt support team, why is that? From experience, because there are too many information that is kept secret unless you pay the Qt people. I know the Qt documentation is well-written, but it’s far from being comprehensive. Well, it’s a broken open-source model.

What I’d like to see with Qt, is:
1. First and foremost, true, non-crashing-every-15-minutes QML live-reload out of the box, with real C++ integration that I don’t have to fill my project with stub codes
2. Actually comprehensive documentations, with necessary quirks and hacks to actually get something out of Qt that you don’t have to purchase Qt support in order to be able to complete any real project
3. Get back Android 4.1 support, I mean, why was it removed? A deadly gift of Qt 5.13


Oleg says:

Felgo (former V-Play) have QML Live Code Reload feature for some time:

So technically it’s possible. Hope this feature will be available in “core” Qt as well.

Elie Zedeck says:

Having to resort to third-party/partner products in order to get basic feature from a given framework is far from ideal. I have explored different solutions, nothing came close to anything satisfying as VueJS to Javascript, or Flutter to Dart. All of them were broken. I suspect Felgo also suffers from the same problem, with the strong partnership with The Qt Company, they were just able to get it a bit further, but nothing amazing. I’m talking about your code integrated with the live reload.
That should not be taken care by a third-party, it should be baked-in already.

Oleg says:

It’s not so “basic” feature in case of non-managed languages (C++ for example), please take a look on my comment below.

Tham says:

Tried, but it don’t work when I combine it with extension written by c++, there are lots of things can’t be done by qml + js or they are much easier to be done by c++, this support is broken.

Oleg says:

Unlike JS/Dart, C++ doesn’t have VM. With C++, you can’t just “stop the world” and (almost) seamlessly replace one code with another. You can unload one C++ dynamic library and replace it with another version of the same library, but in general special measures must be taken and the library must be written in a special way to “preserve state” between versions, because you working directly with machine code, not some VM-driven bytecode with objects managed by GC and so on, so “hot reload” is not easy task with C++. BTW, Flutter doesn’t allow “hot reload” in release mode (when it compiles into ARM/x86 machine code, not Dart bytecode) at all. Dealing with machine code have its own advantages (speed, low resource consumption), but it have disadvantages as well.

Tham says:

It is fine for me, I don’t need QML Live Code Reload, able to run on desktop and a good designer are more than enough. Live Code Reload is a plus, but not mandotory

Jason says:

I think fundamentally that Qt needs to distinguish itself from Flutter. We can’t sit by hoping that Google lets it atrophy.
If I were a developer entering the space today, I would pick up Flutter before Qt. Even though Qt is far more proven, Flutter is more accessible in terms of both technology stack and licensing.

Elie Zedeck says:

Couldn’t agree more.
You could have 100 years worth of features that doesn’t deal with anything UI, that’s not bad, but at the end of the day, it’s all about UI, what the user can see and interact with. Flutter understands this far more than The Qt Company does, which is a shame because I love QML, and it has not seen any love for too long.
By neglecting the UI side of things, Qt has essentially buried its 100 years of non-UI works. Doing nothing about this is so sad!

jackyl says:

Qt should be sell to a big Internet company, like amazon, or alibaba

Tham says:

Or better, Huawei, their Harmony OS could be a big thing in the worlds of embedded devices, IOT.

Leonid Dulman says:

Plane you to add voice recognition to QtTextToSpeech module in Qt 6
Thank you

Commenting closed.

Get started today with Qt Download now