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.
↫ Tim Anderson at Dev Class
Qt plays a significant role in the open source desktop world in particular, because it’s the framework KDE uses. Hilsheimer notes that KDE’s role in the Qt community is actually quite important, because not only is it a source of people learning how to use Qt and who can thus make contributions to the project, KDE also tends to use the latest Qt versions, creating a lot of confidence among the wider Qt community to also adopt the latest versions.
The relationship with KDE and Qt is an interesting one, and sometimes leads to questions about the future availability of the open source edition of Qt since the Qt Company licenses Qt under a dual-license structure (both open and proprietary). To avoid any uncertainty, KDE and Qt have an agreement that covers pretty much every possible scenario and which is worded to ensure the availability of Qt as an open source framework.
KDE, through the KDE Free Qt Foundation, has a number rights and options to ensure the availability of Qt as an open source framework. I’m no lawyer, so I might get some of the details wrong, but the main points are that if the Qt Company ever decides to discontinue the open source edition of Qt, the KDE Free Qt Foundation has the right to release Qt under a BSD-style license within 12 months. The same applies to any addition to Qt which are not released as open source; they must be released under an open source license within 12 months of initial release. This agreement remains valid in the case of buyouts, mergers, or bankruptcies.
This agreement has existed in one form or another since the late ’90s, and has survived Qt being owned by Nokia and Digia, as well as various other organisational changes. Despite the issue of Qt’s ownership coming up every now and then, the agreement is pretty airtight, and considering its longevity there’s no reason to be worried about it at all.
Still, this structure is clearly more complex and less straightforward than, say, the status of GTK and its relationship to GNOME, so it’s not entirely unreasonable the issue comes up every now and then. I wonder if we’ll ever see this situation become less complex, without the need for special agreements. While it wouldn’t make a practical difference, it would make things less… Legalese.
You got me excited for a moment before I discovered that it’s just another way to expose QML-based GUI development.
No thanks. it’s bad enough that Kirigami’s uncanny valley is starting to creep into my KDE, and, if I’m going to be writing in more than one language anyway to access QWidget-based GUI development, I’d prefer stacking Python and PyQt on top of Rust instead of QML… MyPy’s strict mode may be flawed, but it gives more correctness guarantees than anything I’ve found for QML.
There is no reason that you cannot create your own bindings for QWidgets if you wish to. All you need do is create a C wrapper, and you can bind them to whatever language you want.
It’s a very simple thing to create a C binding for a C++ class.
As far as I can tell, no one has done so officially because there really is no interest in doing so for the QWidgets.
I don’t know if I would say it is a “very simple thing”. Simple classes with extern C maybe. But complex classes that take objects and have extensive C++ memory management maybe no so much.
My perspective is “That defeats the whole point of using Rust instead of Python to get stronger compile-time guarantees”.
I’ll just continue to use Python as “QML for QWidgets” via PyO3, PyQt, and MyPy. That way, every layer of my stack can continue to delegate responsibility for memory safety to someone else’s library.
I have always been torn on the idea of KDE being based on a proprietary toolkit.
On the one hand, it is great to have the extra resources and to have people paid to care about the little things that Open Source developers may not. I also have the sense that Qt less likely to fall out of step with the desires of its users over disagreements in vision as some may argue GTK / GNOME do from time to time.
However, there is also a loss of freedom for the overall platform in terms of control and direction. Finally, it just makes the licensing situation more confusing which puts too much emphasis on the license as opposed to the software itself.
Overall, KDE and Qt have made it work incredibly well for a really long time now. Hats off to everybody involved.
Hello, Thom.
I am not sure if you are familiar with Qt, but this issue was resolved long ago. The source code for Qt is licensed under LGPL and GPL. Furthermore, KDE maintains its own set of patches in the event that patches are not accepted by Qt upstream.
There is absolutely no danger of any conflict between KDE and the Qt Company. Even if there is a future disagreement that causes them to go in different directions, KDE will still have access to the existing Qt source code forever.