Comment by jchw | Hacker News Reader

Comment by jchw | Hacker News Reader

Parent Full thread

The problem with Qt Company is not that they are comical villains who do everything they can to thwart open source. The problem with the Qt Company is that they intentionally try to confuse users about what they can and cannot do with LGPL software, gate their SDKs and binaries behind accounts, seemingly tried to break off the KDE Free Qt agreement in unfavorable terms (and this action has led to Qt 5 being maintained mostly by KDE in practice), and generally have pushed Qt in directions that I and many others don't really like. I do understand that it's not literally just to cause harm or out of greed. I'm sure that making a standalone business out of what Qt is, is quite challenging. I remember the many transitions since Qt was acquired by Nokia and split off into Digia. I remember their attempt at the "cloud" with Engine.io. But the thing is, at some point it just needs to be said: it kind of sucks. Qt Widgets was truly amazing in the late Qt 4.x days. Now? It's at best marginally improved from those days, and at worst, much buggier and kludgier than it used to be.

I want to like Qt, but it's difficult. From a pragmatic standpoint, it's just so damn buggy, and rather important issues can take a long time to see any progress. It bums me out that today, QDockWidget is still unusable on Wayland, right now, in the latest Qt 6 release version. Not "ugly" or "janky", but as in, it literally does not work, you can't redock widgets in most cases. Is it because they literally don't care? Nope; in fact, they merged in the fix just five days ago. It does depend on protocol support for fluid animations, but the general concept would've worked from the get-go. But I dunno, it just seems like the priority is and has been quite low for these rather basic usability issues and bugs.

Qt has always been rather buggy and I'd consider it to have been good despite that, but the argument definitely gets harder over time. I think today the only thing I can say is that it's far more mature and full-featured than most other toolkits that are open source, but that's not exactly something to brag about either.

Today if I use Qt I don't bother with the official SDK on any platform, as it's not really worth it. Like, what, do I need to pipe my Qt account credentials into CI? No thanks, I'll build it myself.

I mostly disagree. Like you said, Qt is the best cross-platform native-like GUI toolkit available today. And that is a hard achievement. There are many tradeoffs (some you pointed out) but the open source community seems to find a way around those limitations. There are thousands of open source libraries you can plug-in into your Qt app to overcome many of its limitations (although some remain, like how can't we still not easily change caret/cursor color of QTextEdit??).

Unlike you, I like the direction that Qt is taking. I think QML and Qt Quick are great. I just implemented a feature in my note-taking app that turns Markdown text into Kanban board using QML and the experience has been great (https://github.com/nuttyartist/notes/pull/574). I'm planning to continue transition from QWidgets to QML/Qt Quick.

I do worry of the continuous friction with open source development and hate the online installers as well. I can recommend this useful tool https://github.com/miurahr/aqtinstall that allows you to easily download prebuilt Qt binaries. I hope they can revert their approach on that.

Well, to be fair, most of what I said wasn't actually regarding the direction of Qt. That said, I am sure Qt Quick/QML has improved since I first used it, but I feel like it's not the "next gen" declarative UI design I personally would've wanted. I actually think there's some Rust UI libraries that are going in a direction I find more interesting.

It is what it is, though.

I have been working with Qt since v1 in ~1999. I have written 3 commercial products for Windows and Mac with it. Currently I have a small business license. My gripes are:

-The Mac version has historically been a lot less well supported and stable than the Windows version. There have even been gaps where a new major macOS version came out and it was some time before Qt supported it.

-Too much emphasis on all sorts of new shiny things I will probably never use. I really just want the C++ core and widgets to be super stable.

I understand why. Apple is a dumpster fire when it comes to backward compatibility. Also there is probably more money in shiny new features. But, despite these caveats, overall I think Qt is pretty great.

> The problem with the Qt Company is that they intentionally try to confuse users about what they can and cannot do with LGPL software (...)

Their commercial licenses are very expensive. Qt charges close to $400 per month per developer, or close to $4000 per year per developer. A small shop is on the hook for $50k/year. That's a very hard pill to swallow.

>Today if I use Qt I don't bother with the official SDK on any platform, as it's not really worth it. Like, what, do I need to pipe my Qt account credentials into CI? No thanks, I'll build it myself.

On Windows you can just run the installer and then copy the installation directory from one computer to another. I think it doesn't even touch PATH.

Yeah, but that's not really great for CI purposes. I want to have a good "source of truth" for binaries somewhere, and needing an account to update those binaries is unnecessarily limiting. So I have a different approach; I have one set of CI pipelines that builds a Qt SDK for a given project, then I can use the resulting SDKs in other pipelines. Easy to update, and you can get much smaller builds too.

I've considered doing that, was it hard to set up?

I've never tried to make a terribly general attempt at it, but I have done it a couple times and had it work pretty well.

Here's one of the latest attempts I've done, although I'll note I still haven't managed to get an actual working Apple Silicon build. It keeps building for x64. The Windows builds were smooth sailing since I didn't need to worry about cross compilation yet, though I'm sure it'll be interesting when I eventually try this for AArch64 Windows.

https://github.com/puyonexus/qt-sdk-builder

(I don't do this for Linux since it's easy to get a Qt SDK on Linux.)

Reply on news.ycombinator.com