[happy_dog1]

Funny...I was just coming here to talk about Qt :)

To be fair, as you say, Qt definitely has shortcomings and some things I don't like. If you're trying to minimize your disk space footprint, it's hard to get anything under 50MB with Qt. The difficulty of navigating the licensing for a closed-source app is (while often exaggerated) quite real, especially for someone using Qt for the first time. And while I understand why they did it, it's often annoying to have to use the Qt equivalents of standard library types (e.g., don't use std::string...use QString! don't use int64_t...use qint64! etc.)

The problem is there really just isn't a perfect library or tool for building desktop apps, and writing your own would be...a lot of work. I share the linked post's distaste for Electron, which without a lot of work tends to result in horribly bloated software (often very nice look and feel, but bloated just the same). GTK sounds nice in principle, but you very quickly find yourself missing all of the functionality built into Qt. So Qt often for me ends up being like what someone once said about democracy: it's the worst system EXCEPT for all the other alternatives we've tried from time to time...all of which are worse.

[rubymamis]

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

[ranger_danger]

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.

[rubymamis]

> 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.

[ryandrake]

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...