I have said it once and I will say it again: You really should think twice about buying Qt embedded licenses. Unless you really need an embedded version of Qt the LGPL variant is probably fine for you.
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.
I strongly agree with this, with one caveat: there are a few modules that are GPL and not LGPL. Definitely check the module licenses to make sure you're not going to need anything that is GPL. Most likely you won't.
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.
True, some modules are under the GPL only. Here[0] is a very nice website showing an overview.
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...
> used Qt for many many years, but would like to get away from C++ for UI logic
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?
> 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
Wow, you seem right. That's incredibly dumb. It almost seems auto-destructive.
The commercial variant of Qt is designed to appeal to big players like car manufacturers. Not your small startup which is building a desktop app.
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...
Author here. Can confirm, I asked my boss (small German company with 7 employees) about getting Qt commercial license, because the Qt3d engine is still unusable slow and QtQuick3d looked like a nice alternative. Our product isn't even out yet, and we would have to pay 100k+ without having earned a single penny so far. We now switched to an embedded WebView Godot version for our 3d needs inside our qml desktop app.
Probably the better solution. It is an understatement how hard it is to get out of the commercial licence. If you would find out later that it isn't for you (or the Qt Company raises their prices again, like what happened from v5 to v6).
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?)
They are car manufacturers and known to lock down their systems as much as possible.
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.
They sure do. Many of my customers are small companies or startups shipping desktop apps, they come to us to get a tool that takes the pain out of desktop distribution [1]. Often they're doing things with hardware. Electron apps do count but actually a lot of our users aren't using it.
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 have seen several threads on Qt on HN in the past and was always quite surprised on the takes in the comments section here, especially on Qml, but never bothered to write up a reply so far.
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.
QML is nice, and IMO a much better version of the HTML/CSS/JS web stack. There are also decent debugging tools and it seems to perform well-enough (though you can certainly shoot yourself in the foot).
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.
Creating a multiplatform native framework for creating native looking GUIs is extremely difficult and a challenging piece of work. Add the complexity of C++ and I'm not surprised that things are as complicated as they are.
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 most people aren’t aware of Elm. Despite its good ideas it’s a niche language that should be avoided for real work because it has a bus factor of 1.
I absolutely love Xmonad, and I'm very impressed by how easy its architecture makes it to get complex changes to your environment off the ground. It's a godsend in terms of interfacing with the box, mostly because its configuration is so good, I just wish it had some prettier GUI building blocks to use --- the included packages like TreeSelect and GridSelect are absolutely hideous. I've always assumed their problem could be that no one who can really do UI is interested in an X WM focused on functionality over style, but it's a shame.
Rightfully unpopular if I might say so. I spent the last 2 weeks learning Flutter. I'm not having a good time. Compared to Vue everything takes so much longer. There's a reddit thread in the Flutter community about what people think could be improved upon.
Flutter should decide on standards regarding routing and state management. It's all a hot mess. There should be standards, but Flutter doesn't have them. They're still stuck in the Android way of doing things. There is only 1 oidc auth solution and it only works on mobile.
Null safety and checking is a PITA.
And it's overly verbose.
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.
Using dart and flutter every day for the last 3 years, I strongly disagree with you.
Dart/Flutter is a lower level framework than something like vue, so yes it is more verbose. But there are standars, what you are referring to are just libraries builded on top of them. There are two ways to navigate, a legacy one and a new one, but this is normal in a young framework. State management? You are covered by the framework, wants something different? Just pick your poison between the available flavors.
The base is sane and stable as a young growing framework can be and so is the ecosystem. Can’t say the same about JS
Maybe two weeks are not enough to understand something like Flutter and Dart…
I have an acquaintance that switched from Perl consultancy to Dart/Flutter consultancy and managed to find less work. This was someone that was engaged in the early days of Dart and was part of Google’s Flutter outreach program.
It is unpopular. Its only reason d'etre is being the only language used by Flutter. I'm not aware of any major project using it outside the Flutter apps.
Ah, I should perhaps have clarified. I didn't mean "popular" in the sense of widespread adoption, but. More "for it's domain, is it liked/disliked".
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.
Every language is "popular" with the niche of hardcore supporters who really really like it. Actually-popular languages are the ones who can go beyond that niche and attract large numbers of developers.
Dart is not one of those languages. Dart is just not popular.
I agree about the different ways to interpret what popular/unpopular means. But, "app development" is not really a niche. And having almost 50% market share of cross platform frameworks in that market, and growing, is also no small piece either.
> And having almost 50% market share of cross platform frameworks in that market
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.
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.
I think a lot of the problems come from the incentives the Qt Company has. They get a lot of their revenue from big companies like car manufacturers with very specific requirements. That's why their QML examples always contain a car dashboard. Another part of their revenue is from people who are locked in to their license agreement. They are not putting enough resources into desktop development, widgets, or to make it a competitor to Electron, Flutter, and simliar tools.
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 problem is that the desktop market is fundamentally dead from a commercial perspective. Without the embedding/automotive sector, Qt would have died more than 10 years ago; so it makes sense that they care for their actual source of revenue. You can have the best desktop tech in the world, if nobody wants to pay to do desktop development you're SOL.
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.
Strongly disagree with the "Qt 'tools' should use QML more". QML and Widgets are strong at different things, the tools are relatively clear cases of the things that Widgets are better at. There is no point in shoehorning QML into them just so they use QML, which is optimized for different things.
Qt Quick is catching up with QWidgets. While still some way to go, I agree with the OP that it will align incentives for them to improve edge cases of features that exist in QWidgets but lacking in Qt Quick.
QWidgets look and act like a desktop application. QML looks and acts like a touch screen application. The two use cases are very different. A touch screen application doesn't work well on a keyboard/mouse environment. A keyboard/mouse application doesn't work well on a touch screen.
The Widgets are easier to work with for pure desktop apps… but they are limited to that purpose. Qt Quick and QML are better for pretty much any application use case that isn't the classic desktop. Especially any form of app for mobile or embedded devices.
They have allienated C++ devs by imposing on them the abomination that is QML. The first thing they should do is to provide a public API for using QtQuick solely in C++.
I beg to differ, QML is great. I'm implementing a feature that converts all tasks in Markdown editor to a Kanban view (written in QML) and it's been so easy to do. Work in progress GIF here: https://imgur.com/a/sZNHnp6
And it's even crazier that most of it compiles to C++. It's so fast to develop with it, and runs so fast.
The problem with QML is that it's not C++. Most Qt developers are C/C++/Python folks, being forced to use JS is not their idea of fun. Also, for some time the prebuilt QML widgets didn't have feature parity with the old QtWidgets. I think they're now there, but it's still a different philosophy: QtWidgets tried hard to fit in the desktop paradigm (with tray icons, desktop services, etc), whereas QML simply doesn't care - QML more or less expect to simply take over the screen and do everything on their own, web-style. Again it's a culture clash with traditional QT that QML creators seem to have fundamentally underestimated.
> being forced to use JS is not their idea of fun.
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)
In multiple entities I have worked for over the past 15-20 years, there was a sentiment that we wanted to support the fine folks behind Qt, thus licensed each and every developer seat, to the tune of 4000€. At some point, they started biting the hand that was feeding them: demanded an enterprise-wide usage audit (so we had to involve our Legal team to fend them off), changing the EULA in such a fast pace we couldn‘t keep up, created this forever-keep-paying rule…. Today, at my new employer, I use the LGPL version, like we always could have. No good deed goes unpunished, and I have taken enough battering.
> I have already said it many times online. The way Qt wants to make money is too much focused in big B2B style. There is a general sentiment in the community that the current pricing is bad for small businesses. It feels like giving into a trap when using Qt for small business.
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
> Well guess what, people are just embedding browsers now
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.
I hate embedded browser UIs like electron stuff as much as you do, but you're pointing your blaming finger in the wrong direction:
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).
Nah, I'm not pretending anything of the likes in any way. In fact, the overwhelming majority of apps aren't cross-platform at all, so that's really the norm, not cross-platform frameworks.
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.
Yes to all the above, actually. Using Electron as an example, applications are often >100MB in size, consume >100MB memory on the low end, & (subjectively) perform badly enough that I can easily feel and perceive the delay between interaction-response.
Embedding an entire web browser is the software equivalent of shipping a tiny part in a 2 foot cube box, or putting three layers of non-recyclable packaging on vegetables.
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.
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.
> 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
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.
Just because you have access to powerful hardware doesn't mean others have as well. They have perfectly fine and adequate computers, until we started wrapping everything in electron.
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.
Qt is not bad but it's also not as good as Electron. It doesn't look native (unless you're myopic), it's slower than native, it's quirky, it's buggy... it's cross-platform on paper because when you manage to build your app on another platform you'll see half of it doesn't work well... and on top of that, it costs money. A lot of money. No wonder it lost.
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.
Why bring Electron? Qt doesn't look exactly native, and it is a bit slower than native, but Electron doesn't look native at all and is much slower.
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).
That's one way of looking at it, but remember that Electron is better and free even if you don't release your code. On mobile, you have Flutter, React Native... In this situation, why would anybody want to go with Qt, unless they have an existing, legacy codebase? Who's starting new projects in Qt?
Electron is better if your only metric to evaluate quality is "can I use it in my proprietary product?".
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 second this. On the projects where I work,
I see a lot of 117 reinventions of square wheels,
with their accompanying bugs, for things like
multi-column lists, scroll, selection models, and drop-downs.
And I know we used to have those things as built-in
standard-widgets, where you had to put in extra effort, in order to F them up.
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.)
This. It is incredibly easy to underestimate the functionality in a fully-fledged widget set, especially once you factor in accessibility integrations. UI development is 10% shiny, 90% edge-case.
I cringe when I have to install a Qt app, because at least half of the time, even as a user, I know I'll be fighting with Qt system dependencies. Even if the app is distributed in binary form. The situation gets worse when you have to actually build the source. It seems like the API is never stable, even with minor versions they seem to like changing methods name and breaking backwards compatibility. When I look at what was changed, it looks like change for change sake and I can't tell a difference in how its better.
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.
These are just packaging issues, typically (but not only) on Linux. Dedicated developers know what to do to avoid all of that.
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.
> These are just packaging issues, typically (but not only) on Linux. Dedicated developers know what to do to avoid all of that.
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.
> Qt should create a vanilla c++ package and tooling manager like Rusts cargo for dependencies and tools (and make semantic versioning mandatory). [...] Make the tool open source with vanilla c++ (aka non Qt projects), only so it can become the de facto standard.
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:
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...