Earlier this month I traveled to winterly Berlin for the Qt Contributor’s Summit. After having contributed many patches to Qt in the past months in order to make the upcoming Plasma 6 really shine I decided to attend for the first time this year to meet some more of the faces behind our beloved UI toolkit.
The event took place over the course of two days adjacent to Qt World Summit at Estrel Hotel in Neukölln – a massive hotel, congress, and entertainment complex, and actually the largest in Europe. It literally took me longer to walk from its main entrance to the venue than getting from Sonnenallee S-Bahn station to the entrance.
Thursday morning at 9:30 after registering and picking up our badges, Volker Hilsheimer of The Qt Group opened the event and gave a recap on the state of the Qt Project and where it’s headed. Following that was a panel discussion on how to attract more external contributors to Qt. Being a library consumed by applications rather than an end-user product on its own certainly makes it hard to excite people to contribute or give them a reason to scratch their own itch.
After a copious lunch we started diving into discussions and workshops, typically three tracks in parallel. They were usually scheduled for 30 minutes which I found was way too short for any kind of meaningful outcome. The first meeting I attended revolved around “Qt – Connected First” and how Qt networking APIs could be made more capable and easier to use, particularly in the realm of OAuth2 and JWT. The need for supporting the fetch API in QML was also emphasized. Next I joined “moc in 202x and beyond” with Fabian Kosmale where we discussed ways the Meta Object Compiler, what gives you signals and slots, and is basically just a glorified pre-processor, could understand actual C++ language constructs. After that I listened in on a discussion on improving the API review process of Qt.
Finally, there was a one hour slot by Volker Hilsheimer on evolving QIcon and theming that came out very promising. Linux desktops for the longest time have had a standardized way of loading and addressing themed icons and Qt’s own icon infrastructure is built around that. In recent years, however, most other major platforms, particularly macOS and iOS, Android, and Windows, gained the ability to provide standardized assets for many icons typically found in an application. They even took it a step further and support additional hints for an icon, for example whether it should be filled or just an outline, rounded or sharp, varying levels of “progress” (e.g. the WiFi icon might consume a hint on what signal strength it should represent), and of course dynamic colorization.
Most of those icons are actually implemented using font glyphs and variable font axes addressed via “tags”. Qt 6.7 (its Beta due any minute at the time of this writing) laid the ground work for manipulating those through a new QFont::Tag API and will ship with a “platform icon engine” for the aforementioned operating systems. In KDE we’re quite excited about it since we also dynamically colorize our Breeze icons based on the current color scheme. This is currently done by our own KIconEngine and will not work when run in other environments like Gnome or Android where we instead have to ship a dedicated “Breeze Dark” icon-set using white rather than black icons. There’s now also a QIcon::ThemeIcon struct containing a list of well-known icon names (such as “undo” or “open file”) which will map to the respective native icon name depending on the current platform. And if this wasn’t thrilling enough, Qt SVG also received some love and, among other things, gained support for various patterns and filters, including Gaussian blur.
We then headed out to a Pizza place we didn’t believe would actually fit the thirty or so of us that were looking for dinner there. The next morning began with a presentation on Cyber Security by Kai Köhne and how to deal with CVEs in Qt better since it also ships a lot of 3rd party code. This was then followed by Marc Mutz and a session on the state of C++20 in Qt and of course co-routines. After lunch we continued discussing the Cyber Security topic. Thereafter Thiago Macieira explained how broken QSharedMemory and friends actually are and that there’s no real way to salvage them. The biggest user of it seems to be QtSingleApplication which I reckon should actually be a core feature provided by Qt. There’s a also a few questionable uses within KDE with the most important one being in the KSycoca / KService database.
I then switched rooms to a joint session about cleaning up QMetaType where we scrolled through the code a bit and tried to figure out what problem some of it is actually trying to solve. Finally, Fabian presented his work on extending the QML type system, most notably for supporting std::variant and, by proxy, std::optional. Currently, if an API accepts multiple types of input, such as “model” on a Repater or ListView taking a proper QAbstractItemModel* as well as a simple Array of values or even just a plain number, this has to be implemented using a property of QVariant. This doesn’t make for self-documenting code and poses problems at runtime where at best assigning an unsupported type will print a warning on console. Using std::variant one could declare the expected input up front. Likewise, rather than using QVariant to return undefined if no value exists, std::optional would make it obvious what the main type is but that it can be “nulled”. Furthermore, we discussed type-safe ways to declare the expected signature for a JS callback function such as the “provider” functions in TableView.
We then wrapped up the conference, collected our T-Shirts and whatever leftover merchandise and headed back towards home. Many thanks to Tobias Hunger and his family for their hospitality as well as The Qt Group for sponsoring my travel.