Current issues with the Qt project from the outside looking in
kelteseth.com
kelteseth.com
Everyone who is saying that Qt is too expensive -> It's free. Just Use LGPL. All the tools are GPL but that doesn't matter if you don't want to link against those. The Libraries itself are LGPL so you can dynamically link against them with attribution.
Everyone who is saying that they need the Qt Support -> You probably don't. If you live on the bleeding edge you sometimes get cut. Qt for all its flaws really is fine. And if you get stuck the community will help out just as good.
Everyone who is saying that they already bought into it -> Bad news for you. The license terms of the commercial license are very restrictive. If you are building an application which communicates over a network or building a system which consists of multiple programs you have to make sure you don't integrate or communicate with a program which uses the LGPL variant[0]. Yes that's right, if you pay them money you better make sure that you never run your program on KDE because it would inadvertently communicate with software that you are not allowed to communicate with. Of course you are allowed to communicate with everyone while using the LGPL.
ALWAYS use the LGPL variant! Unless you are not able to work within the boundaries of it.
If you have to spend money you are better off donating to the KDE Free Qt Foundation.
[0]https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-un...
Wow, you seem right. That's incredibly dumb. It almost seems auto-destructive.
If car manufacturers would decide to support upgrading the Qt version by uploading shared objects directly to the car there would be no need for them to buy Qt Licenses. Because technically they could support all points of the LGPL. But that will never happen for two reasons:
1) It is very hard to get out of the contract if you already bought a license. You would have to prove that you aren't using any commercial tools anymore (of course they are the same tools as GPL but installed a different way).
2) They are car manufacturers and known to lock down their systems as much as possible.
The Qt Company probably didn't think about the average C++ Developer or Desktop programs at all while writing these Terms and Conditions...
You even require written permission from Qt to upgrade from LGPL to the Commercial License[0]. Because if you started programming without paying them their fees you probably owe them even more money according to them...
[0] https://www.qt.io/faq/tag/qt-commercial-licensing (If I have started development of a project using the open source version (LGPL), can I later purchase a commercial version of Qt and move my code under that license?)
Have you ever tried to explain the Qt licensing system to the legal department of an automotive, medical, or aerospace manufacturer? I have.
If you can get them to understand it, their faces turn white at the idea of the end customer sideloading new libraries into the device. The conversation pretty much stops there.
On an unrelated note, as someone who mainly builds desktop tools and has used Qt for many many years, but would like to get away from C++ for UI logic, I can't see any reasonable alternative, but would love for some suggestions.
Qt just makes so many things easy, and basically every use-case is well-explored. Most other options seem to just focus on making easy things easy. As soon as you want to render something in 3D, make a node editor, call into or share data with C++ libraries, implement a reasonable undo/redo system, re-skin the UI to not look like a children's app, etc, other options fall flat.
As for alternatives there really is not much to choose from. For small projects which are not reliant on the performance/native designs of Qt, Dear ImGui looks nice[1]. But it is very much tailored for a different Use Case.
Edit: I said that [0] is a nice website. But you only get a complete view of the situation if you cycle through all of the open source licenses. Too bad there is no "Open Source" option. Would hurt their sales I guess...
i've been thinking about this lately.
objc/nextstep got swift.
c/gobject got vala.
c++/serenity is getting jakt.
these are all higher-level compiled languages whose design is directly informed by the corresponding framework apis.
especially in the olden days, when qt wasn't as much c++ as moc/c++, it would have definitely seemed like there was another language in there. why hasn't it been extracted?
That is an excellent link to a well-written article that untangles Qt licensing. Thank you!
I have always found Qt licensing to be almost designed to be as confusing as possible. Unless you deal with Qt on a daily basis it could take weeks to understand what this article lays out clearly in one page. I've always considered the framework to be something "radioactive" to be avoided due to this issue.
I myself am mainly a C programmer, doing low level stuff, with occasional detours into C++ projects.
In 2019/2020, I worked on a larger project replacing a web based UI on an embedded device with something Qt based, not having touched Qt since version 4. Due to some of my older spare time projects, I have somehow become the go-to graphics guy in our company, but usually those issues revolve around questions like "why does the display bridge do those bizarre things?". This projects was IMO a quite interesting excursion outside of fiddling with graphics drivers.
Yes, I was a bit put of by Qml at first too, but eventually found it a breeze to work with. Qml is a language for designing both the UI layout and UI level interactions. Writing code and trying it out was a very refreshing change from having to fiddle with some IDEs Visual UI designer. I managed to cobble together complete mock-up clone of some of the existing UI screens in only an afternoon, rather than e.g. 3 or 4 days as originally budgeted in some cases, spending the rest of the time on "fine tuning" and starting with the back-end integration.
Combined with Qts emphasis on Model-View-Delegate design this allowed us to very cleanly separate the UI from the actual logic, to the point were the UI would work like a LEGO brick stuck on top of the application logic.
Even as a die hard C programmer, I would say I liked working with Qml and it is definitely something they did right.
But a lot of the QtQuick components and the language itself have weird edgecases that are never documented and probably just simply bugs.
Building reusable components in QML isn't easy. A lot of available properties depend on how you instantiate the component, and it's not always possible to specify exactly what properties you expect to be bound (this is where a lot of the edge-cases that I noticed come in). Components seem to be a somewhat leaky abstraction, especially when used as delegates in views.
And the actual IDE integration of QML into QtCreator is just bad. It's frustratingly slow, loses type information of components very easily, doesn't even highlight properly a lot of the times and has no other advanced integration. It's weird. You'd think such a tightly integrated language could have amazing IDE support, but it just doesn't.
I once looked at what needs to be implemented to implement a text control interface in Mac OS and it was an API with hundreds of methods.
GUI frontend development IS complicated. There's so many edge cases with text rendering, editing logic, layout, state, native compatibility.
I started writing the beginnings of a flowing rendering engine using WxWidgets in Python using an algorithm from the ORC Solver whitepaper.
IntelliJ Idea, Netbeans are intricate advanced frontends and they are both written in Java.
How would a user interface written in a functional language look? I used to use Xmonad as a window manager which was very powerful and easy to use but it is written in Haskell.
I think any frontend technology that wins needs to be simple and easy to comprehend. I have yet to use Flutter.
I did have a frontend in Electron but my code was awful.
I would rather create user interfaces with a simple language and use a fast language for the data crunching. I think Python and Java count.
Maybe you're not aware of Elm?
Elm is really functional, unlike the likes of React that are just partially, kind of functional.
There's an attempt at bringing Elm to the desktop, the Roc language... here's an UI example written in Roc:
https://github.com/roc-lang/roc/blob/main/examples/gui/hello...
When I think introspectively I didn't want to use it because I was never sure what it gave me over what I already used.
There was also the abandonment of Google Web Toolkit (GWT) which I liked that Google abandoned and that I wasn't sure if Dart has staying power.
However dotnet MAUI isn't any better.
So I'd rather do electron with Vue/Quasar. Why bother with native apps? Qt is too expensive.
Maybe two weeks are not enough to understand something like Flutter and Dart…
My two cents
I've used it to build complicated app that interacts with low level C++ code, and I found it exceptionally well put together. High level UI code by flutter was a pleasure to work with, with interactive development and hot reloads.
Low level performant development with all the tools and legacy of C++, and all of it put together and debugged with fairly powerful tools as well.
I cannot think of any stack that could solve the same problem. That is, without having to build separate apps for Android and iOS. And even then, I'd consider it a more productive environment to use flutter even if you target one of the platforms.
And then, the language features themselves. Dart handles null safety in a way no other language and tooling does. It goes beyond null-handling syntax, and can give runtime-guarantees (assuming you check the remote code boundaries) for null safety.
The package management is great. So, if the languages is solely a great development environment for mobile apps, with the potential for desktop/web targets... I would say great job all around.
The only negative/red-flag this has is being managed and driven by google.
---
I've been a developer for the larger part of my life now, and I very much respect the dart language and project. It is well put together, does the right abstractions at the right places. The syntax is great. The standard library is satisfying. The tooling and OS abstractions are great. And I would honestly place it top 3 in terms of enjoyment and productivity. The top three being perhaps rust and kotlin.
Dart is not one of those languages. Dart is just not popular.
Is this really true? I've encountered very few Flutter apps as an iOS user — actually I can't think of any that I haven't intentionally downloaded to see what Flutter is like.
- https://www.statista.com/statistics/869224/worldwide-softwar...
Combined with: https://insights.stackoverflow.com/trends?tags=flutter%2Crea...
Given that the first one was limited at 2021, I would be surprised it isn't around 60%. And, having used react-native and done extensive eval on it, flutter is by far the better architectural approach, so I expect this trend to continue (unless google cans the project that is :P). IMHO, the only reason to ever pick react-native over flutter is if you already have JS developers.
What Qt would need on the desktop is that they put Qt widgets on a new, modern, compositing based foundation (like Gtk did) in order to support transparency, animations etc. Then implement up to date themes for macOS and Windows (using foreign drawing if possible). The macOS theme is clearly outdated and still has blue buttons. Modern WinUI is not included at all. Yeah folk wisdom is that you cannot make a convincing native app this way, but you can get 95% there, and it will be much more native looking than any electron app. I don't see any of this happening, though.
The real target should be phones. QT should have been what Electron became. To be fair, they tried with QT, but it was a day late and a dollar short - as web-like as it is, it's not real web. If you want one codebase for web and mobile, at the moment you'd never pick QML.
What they could do is competing with Electron: provide a better, more featureful way to package advanced webapps. But it means stepping back a lot, and competing with free is hard. Or they could go back to QtWidgets, but it feels like that ship has sailed - apps these days don't even try to fit in with the phone's own native style.
QWidget is the "old" desktop UI toolkit that is good for desktop UIs.
But since to run it still needs a main() to call the QML part, probably js developers stay as far away from it as possible.
QML is not JS. Indeed, lots of high-quality QML applications use basically zero JS inside their QML, and heavy JS use is widely (but not universally) considered an anti-pattern. If using QML is forcing you to write meaningful JS (vs you choosing to use JS for whatever reason), you are probably holding it wrong. (sure, technically "property: a + 15" involves JS because "a + 15" is a JS expression, but not in any sense that a C++ programmer would mind)
And it's even crazier that most of it compiles to C++. It's so fast to develop with it, and runs so fast.
BTW, source code here: https://github.com/nuttyartist/notes/pull/574
QT is pivoting towards embedded industries away from pure Mobile/PC markets.
This. And might I say, a lot of IT companies in Europe are awful at pricing. They're aiming for the B2B market and forget all the others
Well guess what, people are just embedding browsers now and except for niche apps, few people care about Qt
Which is incredibly selfish and hypocritical, it drives up resource consumption across the world at a massive scale. Not just in terms of energy use, but it also forces people to buy more powerful machines, intensifying electronic waste problems.
Great job guys!
The cheapest stuff that can run Qt is the same one that runs a basic Android install
Why no? Not every machine is your 32GB RAM machine… If it has to run on a slower machine… say a raspberry pi with a slow flash drive and a slow external drive accessed over USB… being much smaller means speed.
> Lack of computing power or RAM? No.
Why no? Yes.
We have had multitasking operating systems for a while now. Electron apps are tolerable because they are few. If every single application was done with electron, it'd be worse than windows95 on a 486.
They still sell lots of computers with 8GB of RAM, although I'm sure your one has at least 2x, probably 4x as much.
> Then?
Then, with incorrect assumptions you can reach any result that you desire, but it is meaningless.
This runs a web browser no problem. No need for 32GB of RAM
It'd be hard to find some hardware today that runs Qt and not a web browser that's significantly cheaper (and will just make your development costs higher)
Electron is an issue but nobody is using that for embedded
> Then, with incorrect assumptions you can reach any result that you desire, but it is meaningless.
Exactly
Qt works fine on embedded. Quite popular there.
> This runs a web browser no problem. No need for 32GB of RAM
Yes, 1 web browser with a minimal no js page. But 10 at the same time? 20? Animated stuff in it?
Storage might be cheap, but storage you already have is free. I have a drawer full of old hard drives - all perfectly functional, but not useful because software footprint has exploded in recent years. Embedding a full web browser isn't the only offender, of course - the various types of container systems are another.
And that's without mentioning deployment: It's easy to take a fast, high-quality always-on internet connection for granted, but there are many, many people who don't have that, or use mobile plans with strict data limits.
Very very wasteful.
Now they have to spend their hard-earned money, and contribute to global electronic waste and resource consumption issues, just to be able to participate in society and save face.
It's exactly your attitude that is at the root of this crisis.
Are you saying electronic waste and increasing energy consumption aren't problems anymore?
What do you expect application developers to do in absence of a natively compiling cross-platform GUI lib that is both good and with a nice licensing terms (e.g. a permissive open source license)? To put their application development on ice so as to develop that (which is a huge task in itself)?
If you want this situation to change and shitty browser-based UI to not be the go-to solution (for lack of a better cross-platform alternative for application developers), then feel free to go ahead and develop a native-compiling cross-platform GUI lib that plays in the same league as Qt, and make it available under a permissive open source license (unlike Qt).
All I'm saying is that unlike the native platform-specific frameworks (which are limited to the respective platform, but which the platform vendors make available free of charge under terms favorable to commercial app development), there no cross-platform frameworks that are simultaneously good and not encumbered by totally grabastically shite licensing/pricing terms, thus naturally leading to a wide majority of application developers either going platform-specific… and a large part of the rest (i.e. those who still want to do cross-platform) going with the ugly embedded browser solution (electron and the likes).
The browser-based approach, ugly as it is, happens to unfortunately be the only cross platform solution that is not encumbered by shitty app-developer-unfriendly licensing/pricing terms. Make a good, feature-rich and comprehensive cross-platform UI framework that is suitable both for desktop and mobile applications available under a nice permissive open-source license and you'll see lots of app developers use your framework instead of reluctantly using that browser shite (electron and such).
The dilemma is: who's paying for the development? A good feature-rich comprehensive UI framework is an enormous effort (both upfront and ongoing), and recouping that enormous cost is far from obvious unless falling into one of these categories:
* Platform-specific (i.e. not cross-platform): framework development financed by big platform vendor who makes framework available for free but platform-specific, in order to push their platform and make their money with the latter
* browser based frameworks: framework development cost greatly reduced by re-using a pre-existing browser engine developed by some big player who finances browser engine development because they have a commercial interest in pushing their browser
* Choosing a license that makes the financing of the framework possible by making the app developers pay mucho money… but then it will naturally be avoided by most app developers, especially given the existence of free alternatives (which may have other disadvantages, but those are orthogonal to that problem)
* A big player subsidizing the development cost by some cross-financing from money made otherwise: that has happened for some open source software and libs in other domains, but not for a good cross-platform UI framework so far unfortunately.
On one hand I understand it's good to have competition. On the other, I'm happy that bad solutions lose. That's the way of the market.
I work in a company that uses electron. The amount of time the UI guys spend to reimplement things that are already in Qt is incredible (for example a portable tray icon, menus, tabbing).
Yes we are saving money on license (but spending probably much more on developers reimplementing things).
> Who's starting new projects in Qt?
People who want portability and are aware that not everybody has 32GB of RAM like their overly expensive developer machine?
People that do not feel like reimplementing things that have existed for ages is fun?
People who do open source and do not have to pay for a license, and thus have no reason to "save money" and use electron?
I have an open bug registered on the aurelia framework concerning virtual scroll sometimes breaks when you reach the edges. The answer from the maintainer could be translated to "the guys who understood this code is no longer here". I tried to figure it out from the source code, and came to the same conclusion.
It's as if, ever since we got a full set of widgets available on desktops, we have been busy re-inventing them from scratch in other idioms (notably in the HTML DOM.)
Qt is kind of a middle ground between low level / native frameworks and web based interfaces like Electron.
And in the majority of the cases, it doesn't cost money. The open source version is LGPL, which means you can use it for free in proprietary software as long as you allow the user to modify the Qt library you are using (usually, in means dynamic linking).
This is the plan I am on as an Indie developer.
It happens so often that I'll avoid a Qt app because the dependency management is so bad. Then once you finally get it to work, be prepared to spend time on Stack Overflow researching arcane QT_ environment variables to fix things like display scaling and added additional library paths at runtime.
It's been this way as long as I can remember, and the problem has persisted across versions and different OS and systems I've had over the years. I can always get something working, but it just feels like nothing ever just works out of the box.
Also QT applications seem like they are more unstable to me, more prone to crash and just not work well. I'd rather have a runtime error in some javascript frontend than the entire app crash, and have to pour through enormous stack traces through crazy overly abstracted code that shows a list or runs some tab component.
Then there is the style, at least the one that comes out of the box. Very inconsistent and relying too heavily on platform features that make the app look and behave differently on different OS's. It must be hard for developers to customize because you rarely see a polished Qt app, they all look the same and have the same quirks and lack of padding, spacing and consistent typography.
The last thing is kind of personal, but I tire of seeing the word Qt everywhere. We already know we are working with Qt, you don't need to prefix every single class and package with it. I get this may have to do with namespacing, but in practice it just makes source harder to read and debug.
As for the style - again, depending on developer choices, they can actually be the most consistent with the platform they run on. Unfortunately that was a selling point for the original QtWidgets more than QML - QML does things "the web way" and just doesn't give a crap about desktop styles.
Things like "lack of padding" sound funny to me, because on that side Qt is definitely superior to the overpadded monstrosities of GTK or web-like frameworks, who waste screen real estate for fun. Qt simply uses desktop conventions, which are "just right" in QtWidgets with minimal attention to layouts.
> I tire of seeing the word Qt everywhere
Now you're just being silly. Everyone does it - Apple with NS etc.
Isn't that the point? It's easy for a packager to get into a situation that gives the end user a shitty experience. You shouldn't need to be a "dedicated developer" just to be a user, and making the packaging situation straightforward for the distributor is firmly in framework provider's ballpark. This isn't something Qt should be allowed to shrug off, it's exactly the job they should be doing.
>> Then once you finally get it to work, be prepared to spend time on Stack Overflow researching arcane QT_ environment variables to fix things like display scaling and added additional library paths at runtime.
Just to add my n=1 anecdata here, FreeCAD (a QT app) consistently gets scaling wrong, on all the platforms I regularly use it on (Windows, MacOS, Linux). It's just... not good, to the extent that I actively avoid plugging external monitors in rather than screw with it once I've got a tolerable setup.
Or just use one that is already working: https://build2.org (bonus point: also gets rid of CMake).
There are even "Qt classic" packages for both Qt5 and Qt6: