Special year, special events; Qt is participating at the first-ever Virtual Consumer Electronics Show 2021. You will find the latest news and demos at our virtual exhibitor booth, especially our consumer and automotive industry offering with Qt 6. Virtual CES takes place from 11th to 14th January, 2021 on CES’ website. 

It is with great pleasure to announce that we have released a new version of Qt for Python for Qt 6 and a range of new features 🐍. PySide was initially released for Qt 4 and PySide2 for Qt 5.12. We have decided to follow the general Qt release versioning with this release, explaining the version leap to PySide6 and Shiboken6.    

I am really excited to announce today’s release of Qt 6.0. It is the first release of a new major version, and marks a major milestone for Qt. We started working on the initial ideas a few years ago, and since then, have put a massive effort into creating the next generation of Qt.

For Qt 6.0, we have been focusing on improving the essential modules and selected add-ons. There are more coming, though, so I wanted to update you on our ongoing work to port additional add-on modules to Qt 6. This blog post provides an overview and a rationale for our planned timeline.     

Embedded developers have been using the open source meta-qt5 layer for years with their OpenEmbedded and Yocto builds. We have also been using it extensively in our Qt for Device Creation product and have tried to do our part in keeping the latest Qt version available in the upstream layer. With Qt 6 on its way, there was a clear need for a new meta layer for providing continued support for building Qt for embedded devices. 

The delivery of mouse and touch events in Qt Quick is complex, and it became clear a few years ago that we needed to refactor the event inheritance hierarchy, to have some common API for various event types, so that more of the delivery code could be shared. In Qt 5.8 we added QQuickPointerEvent and associated types, as a way of prototyping what that could look like. They are QObjects; and since then, QQuickWindow has been delivering these wrapper events that carry the original events inside. Now finally in Qt 6 we have been able to complete the QEvent refactoring, so that QQuickWindow no longer needs the wrappers. Along with that, we were able to add a few features and fix a few bugs. Many of the remaining bugs that seemed intractable in Qt 5 should at least be possible to fix later on.

Qt 6 is coming with many new features under the hood. One of the most exciting features that we have added is to bring the concept of bindings from QML and Qt Quick back into the heart of Qt and allow using it from C++.

Porting from Qt 5 to Qt 6 has been intentionally kept easy. There has been a conscious effort throughout the development of Qt 6 to maintain as much source compatibility with Qt 5 as possible. Still, some effort is involved in porting. This short post summarizes some of the steps required when porting to Qt 6.

Qt Quick Controls 1 was our first UI framework for QML. The controls were mostly written in QML without much C++. At the time, QML was still a new technology, which meant that we didn’t have enough experience with designing for performance to know what to expect. So the styling API ended up inefficient by design, with many fat delegates that used extensive amounts of JavaScript, bindings, introspection, Loaders, and QObjects for both control logic and styling. It also had a linking dependency to Qt Widgets to get native styling and Widget-based dialogs. And without the QML compiler that we have today, this all ended up as a rather slow and messy approach. When we realized that it also didn’t perform well on embedded hardware, it was time to rethink the solution. And the result was Qt Quick Controls 2.

QLocale looks after all localisation (or L10n) within Qt; while Qt 6 has swept away a few last fragments of L10n built into other things, that now consistently use the C locale (and advise you to use QLocale if you need L10n), it's also seen some significant improvements to how QLocale does those things, particularly in relation to numeric texts and surrogate pairs.

While Qt solves many of the typical tasks of writing an application, there are always corner cases that Qt can not cover, or where it makes more sense to build a feature on top of the platform specific APIs, or another toolkit. One of the tasks we wanted to address for Qt 6 was to clean up and coordinate the various mechanisms we had for accessing platform-specific functionality.