Volker Hilsheimer, chief maintainer of the Qt project, says he has learned lessons from the painful Qt 5 to Qt 6 transition, the importance of Qt Bridges for using Qt from any language, and the significance of the relationship with the Linux KDE desktop.

Hilsheimer goes back a long way with Qt. “I started using Qt in the late 90s,” he tells DevClass at the Qt World Summit in Munich. He then joined Trolltech, the Norwegian company that originally developed this cross-platform user interface (UI) framework, in 2000. Nearly three years ago he became chief maintainer for the project, at what is now The Qt Company.

A key thing to understand about the Qt framework is that it includes two different ways of rendering a UI, an older one called Qt Widgets which has a C++ API, and a newer one called Qt Quick which uses the QML (Qt Meta-object Language) to define a UI and includes a JavaScript engine called V4.

“The entire software architecture of Widgets is fundamentally different from what we have on the Quick side; there is practically nothing in common,” says Hilsheimer. “Widgets came from the days when MFC (Microsoft Foundation Class Library) and Win32 APIs and equivalent APIs on other platforms were the way of thinking about UIs … whereas Quick is inspired by composability … a declarative approach where you assemble your scenes, you assemble your UI elements, and then the rendering goes through the scene graph and has hardware acceleration.”

There is a ton of existing code that uses Widgets so it is not going away; equally it is not a big focus for future improvements. “Compatibility on that side is more important than enabling new features. We are still maintaining it, we still get contributions to it.”

That said, there is work under way to create a hardware-accelerated imperative API for drawing graphics, to enable what Hilsheimer describes as “hardware-accelerated rendering of throwaway frames.” This would involve implementing something like the QPainter C++ API for Qt Quick, “bringing the methodology of QPainter into the Qt Quick Stack,” he says.

This might make the migration to Qt Quick easier; but the work could also benefit Widgets. “What we hope to be able to do once we have implemented this is to also render Widgets using that hardware accelerated painting infrastructure … that is research still, we don’t know what aspects of Qt Painter functionality we will be able to implement,” adds Hilsheimer.

What is the thinking behind Qt Bridges, which enables Qt to be used easily from programming languages other than C++?

“There is a huge community of non-C++ developers out there and they need and want a modern and powerful UI framework.” These developers will not want to use the whole Qt C++ API, but only the UI framework. “The technical problems we need to solve are primarily on the data integration, how do you make the data structures that you have in Swift or Rust available to the Qt Quick runtime?

“The other aspect is that building competence in Qt Quick doesn’t tie [developers] to the success or not of C++.

“The language landscape is evolving. We don’t know where the next Rust is going to be … maybe Rust is not so great, maybe it should be Zig instead or Julia, we don’t know what in five years the language community will prioritize.” Making the QML runtime sit on top of “practically any language” will give Qt flexibility.

The Qt 5 to the (now current) Qt 6 transition was a difficult one for Qt users. The problem was not the actual process of porting, Hilsheimer tells us, but that “we made the decision not to have all the Qt 5 features in the initial Qt 6 release. It was a trade-off; let’s get the essential stuff out first, let’s get feedback before we throw ourselves at the more challenging and less frequently used modules.”

The result was that many customers could not migrate, in part because they used third party libraries which could not migrate immediately. “I think Qt 5 to Qt 6 was much easier than Qt 3 to Qt 4, or Qt 4 to Qt 5, but is was also a much bigger problem because the ecosystem had simply grown,” Hilsheimer says.

The lesson here is that “before customers can make the move, all of that ecosystem needs to move,” he adds. There is no sign yet of a Qt 7 but if there were, “the value of moving to Qt 7 needs to significantly outweigh the cost for the entire ecosystem to do so … we need to understand what are the problems that we want to solve with Qt 7 that we can’t solve within the Qt 6 architecture.”

One of the consequences of this difficult migration was a decline in open source contributions to Qt. “Everyone was focused on their own projects, the KDE community took that opportunity to say, now that we need to break binary compatibility let’s also fix our own architecture and that took them a couple of years.

“Once they were done and once they were building largely on top of Qt 6 we saw a spike again in contributions from that community.”

That said, “contributing to Qt is not easy, it’s a C++ framework with technical challenges,”  Hilsheimer says.

The KDE desktop uses Qt, how important is that for the framework? “It’s very important for us for two reasons,” Hilsheimer tells Derv Class. Mind share is one. “The KDE community has a ground where people can learn how to build applications with Qt.

“The other aspect is that a surprising amount of customers are looking at KDE, not only because some of the KDE frameworks are used by customers, but also from a feeling of safety that they are not the first ones to try the latest versions of Qt,” he said.