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:
- 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
- Its scalability from low-end, single-purpose devices to high-end complex desktop applications or connected system
- World-class APIs and tools and documentation, simplifying the creation of applications and devices
- Maintainability, stability, and compatibility, allowing to maintain large code bases with minimal effort
- 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.
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.
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.
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.
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.