Lars Knoll, KHTML Engine Creator, Qt Project Project Manager and technical director of Qt Companand, he talked about plans to create the next significant branch of the Qt framework. After the formation of the Qt 5.14 branch functionality is completed, development will focus on the preparation of the Qt 6 version, which is expected by the end of 2020.
Qt 6 will evolve in order to ensure compatibility with Qt 5, but it is not ruled out that individual problems may arise, as planned architectural changes and cleaning will not be possible without losing a certain level of compatibility. To ease the transition, some Qt 6 features are planned to be included in abbreviated form in Qt 5.14 and Qt 5.15 versions LTS. A toolkit will also be prepared to facilitate migration to Qt 6.
Among the top goals for the next major branch is to align functionality with 2020 requirements, clean up the code base, and simplify project maintenance.
These are the expected changes
Among the main changes that are planned for Qt 6 is the ability to compile QML into a C ++ representation and machine code.
As well as full support transfer for JavaScript to the options category (using a full-featured JavaScript engine is resource intensive, preventing the use of QML on equipment such as microcontrollers).
It is planned to add a new abstract layer, Rendering Hardware Interface (RHI), to ensure smooth use of various graphical APIs, including OpenGL, Vulkan, Metal, and Direct 3D (previously Qt was tied to OpenGL only).
All existing rendering infrastructure, including QPainter, Qt Quick Scenegraph, and Qt3D, will be converted to RHI. It is also planned to add the Qt Shader Tools module to support various shader development languages and provide cross-compilation of shaders both at the assembly stage and during program execution.
Unification of tools to create a user interface
To avoid duplication of functionality and stop supplying two separate products, Qt 3D Studio functionality is expected to be integrated into Qt Design Studio, many of which the subsystems and plugin connection framework are built on a single code base with Qt Creator.
Qt Design Studio also plans to provide quality integration with content creation packages such as Photoshop, Sketch, Illustrator, Maya, and 3D Max. The main languages supported in a Unified Development Toolkit are C ++, QML, and Python.
It is expected to prepare a unified API to create user interfaces that combine 2D and 3D graphics elements. The new API will allow QML to be used to define 3D interface elements without using the UIP format.
In the new interface for integrating 3D content with Qt Quick, they plan to solve problems such as overhead when integrating QML with content from Qt 3D or 3D Studio, and the inability to synchronize individual frame-level transformations and animations between 2D and 3D.
Joint 2D and 3D rendering will be implemented using the new rendering engine. A preliminary implementation of the new Qt Quick with 3D support is expected in Qt 5.14.
Add tools to process graphic-related resources at the compilation stage, for example, to convert PNG images to compressed textures or to convert shaders and meshes into binary formats optimized for specific computers.
Unification also implies the ability to access Qt Creator to interact with design tools and provide interface designers with developer tool opportunities.
Of the other changes that stand out are:
- Version denial in QML and a unification of data structures that are duplicated in QObject and QML (will reduce memory consumption and speed up startup).
- Avoid generation of data structures at run time in favor of generation at compile time.
- Hide internal components by using private properties and methods.
- Improved integration with development tools to refactor and diagnose errors during compilation.
Source: https://blog.qt.io/
QT would have to use its weight to force a damn single sound system for Linux desktops running QT. As Google does on Android, all applications have to use the Android audio infrastructure.
And hopefully this version brings attractive features and increasingly ease of development and interoperability. We need QT to unseat GTK once and for all important projects to go to QT. GTK is not only backward and old (if it were to catch up with QT there would be no problem with QT disappearing) but the existence of both platforms is one of the causes of confusion, fragmentation and duplication of development efforts and resources in the GNU / Linux ecosystem.