Hacker News Reader

Comment by pjmlp | Hacker News Reader

To note for the usual Qt bashers:

"Thanks to The Qt Company and ICS the current Qt 6 version, 6.4.2, is also available as Bullseye's backports. The Qt Company really also helped us here by providing us almost-to-be-released tarballs of Qt 6.4.2 so we were able to push them to unstable and do a transition in time for freeze, thanks a lot for that!"

View on HN

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.

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

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.

Which point of criticism is this meant to address? In a normal open source project they wouldn't have to rely on the company providing the source code in tarball form as a special favor,

>Which point of criticism is this meant to address?

That they don't release updates for Qt6 anymore (they did)

Yeah, I'd have preferred a more streamlined pipeline like other FOSS projects but still, Qt is like, _the only_ no-nonsense cross-platform option that we got.

In serious GUI libraries space, there is Windows, there is Apple, and...that's pretty much it. I mean unless Elon gonna chip in and pay for development of it, we can't expect competent people work on an alternative to these giants for free.

(This comment references Tesla using the LGPL version of Qt in their cars at no cost. Lots of automotive projects use Qt but generally the commercial variant.)

>Tesla using the LGPL version of Qt in their cars at no cost

lol really?! I didn't know! I just plugged in his name since he has become Tony-Stark-archetype for "tech enthusiast" crowd.

> Which point of criticism is this meant to address? In a normal open source project they wouldn't have to rely on the company providing the source code in tarball form as a special favor,

No, you misunderstood this one.

A lot of major open source projects have processes where source tarballs are released to distro packagers a short while (e.g. a week or a couple of days) before the public release announcement and public tarball availability. This gets you last-minute testing, and makes the distro partners happy because they get to brag about same-day packages when the release goes live, which also makes the users happy when they read about the shiny new release and wonder if they can get it yet. KDE has been doing this for 20 years via it's packagers mailing list, and so do many others.

If you don't it that way, dumb things happen like distros releasing RC tags as "we have the release now" so they can announce same-day availability, and occasionally bugs slip through. Been there, done that.

You probably understood this as "normally you could just look at the git repo", but that's also true for Qt 6.

That probably meant source tarballs of a Qt release before the actual release happened so that Debian could take it in before their freeze deadline.

Release tarballs are and have been available on download.qt.io. And git repository is also open.

Debian includes unmodified tarballs in its archive for its source packages, so since they needed it before the freeze, they definitely would have to rely on that in similar scenarios.

Reply on news.ycombinator.com