Just wanted to let you know it's not all gray in Qt land.
The open-source Qt is licensed under LGPL. It's not really a mystery. I've built a proprietary app[1] on top of that, and as I explained in my blog post[2], the LGPL allows you to statically link your executable as long as you provide the object files and allow users to relink your app with a different version of Qt.
There's also a lot you can do to drastically limit your binary size. I wrote a little about it on my blog post but haven't experimented that much with it yet. Things like:
1. Compiling Qt from source with only the specific modules needed and using static linking.
2. Use the -optimize-size flag and Link Time Optamization flag -ltcg.
3. Running strip on the resulting executable to remove unused symbols.
4. Use UPX to compress the executable.
BTW, Qt can look very native, if you know how to use it properly (I wish to make it more commoditized!), for example, something I'm cooking at the moment:
Windows: https://imgur.com/8lT0u24
macOS: https://imgur.com/a/GKWSDaK
[1] https://get-notes.com
[2] https://rubymamistvalove.com/block-editor#10-qt-license
Heavy Qt user here... I agree with everything you said. I think a lot of people are rightfully confused about the licensing because I think the Qt Company is vague about it on purpose, they want to sell licenses of course. I just hope their agreement with KDE never ends.
I also think that the vast majority of people that complain about the lack of "native look" are bad takes from people that don't actually ship apps professionally and listen to their customers. End-users don't actually care and it really simplifies things a lot to do it the way they are. wxWidgets uses platform native APIs and I would argue that it looks much worse (and old) compared to Qt.
One thing I will say though is that the fact that Qt specifically now uses LGPL version 3 as opposed to v2 (switched in 5.6 I think), can actually be quite significant and a non-starter for some people. If you're developing something where Qt is embedded fairly deep in to the system, especially if it's a critical system, you don't want to have to give the user the ability to swap out your Qt library with who-knows-what and now all your safety testing/validation/warranties etc. are void... which I guess for bigger companies they just buy a commercial license in that case.
> I think the Qt Company is vague about it on purpose, they want to sell licenses of course. I just hope their agreement with KDE never ends.
Yep, I agree. And I hope so too.
> I also think that the vast majority of people that complain about the lack of "native look" are bad takes from people that don't actually ship apps professionally and listen to their customers
Ding ding ding. Exactly. I would argue that most Qt developers aren't targeting the same audience that native iOS developers target, for example, which causes all Qt apps in the wild to look embarrassingly ugly and out of place. The Qt Company's own lack of taste in design (and their examples) doesn't contribute. It's only when developers with a strong taste for aesthetics and for creating experiences that delights people will take on Qt to develop apps, we will see and be able to show the world the power of Qt. I hope to be part of this change, I'm trying to push Qt limits with every new app I make. And honestly, QML is just an amazing joy to program in. Here's a cool window animation you can do in 1 minute using QML:
https://custom-downloads.s3.us-west-2.amazonaws.com/qml-anim...
What we also need is to create a set of beautiful, easy to use components that work out-of-the-box for developers to tinker with. This is very lacking in the Qt ecosystem compared to other frameworks.
The gist I'm trying to get at is that Qt is not the limiting factor, the limiting factor are developers whose both their target users don't care about aesthetics (or so they think), and developers who themselves lack a good taste (or the know how) for good design.
Not sure about the difference between LGPL v2 and v3, but like you said, if you're a big company, paying for the license is a non-starter (and also helps fund Qt development so why not?), but for almost all developers the LGPL version should be more than enough.
Yea, Qt is a pain, but so is any kind of porting work.
I've got a medium sized hobby project I work on that has a macOS and iOS version, separate GUIs, but sharing a lot of underlying code. Every once in a while, I think to myself "It would be nice to port this to Windows and Linux, just for the fun of it" and it always goes this way:
I end up reaching for Qt, but getting absolutely mired in things like: creating the .ui file in Qt Designer, making each screen and dialog equal to the original macOS app in features, converting things back and forth to QStrings and QObjects and QThis and QThat, cobbling together UI logic from scratch that we just get for free from Cocoa like bindings and connecting events to Objective C methods.
Then, when I'm absolutely not having fun here, I'll tell myself "OK, let's just create a native Windows application. Hmm, what's the recommended idiomatic windows way to create an application these days? Is it Win32 still? No, is it WPF? Is it UWP? Is it WinForms? Should I use C# and .NET or not? Before I even write a line of code, I'm already exhausted and demoralized.
Then I think, fuck it, let's start playing with Javascript and electron and all these other things that I only read about on HN but never learned or dove into. By the time I'm done yak shaving to get an environment set up and going through "How to declare a variable" tutorials, I'm wondering why not just add some fun features to the macOS app instead...