Adventures in Debian's Qt Land | Hacker News Reader

Adventures in Debian's Qt Land

perezmeyer.com.ar

77 pointsjandeboevrie39 comments

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!"

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.

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.

I made myself independent of the "Adventures in Qt Land" by switching to https://github.com/rochus-keller/LeanQt.

I read the README and I really don't see the point. So the dev locked himself to an old 5.6 (2016), and then only has a limited subset of Qt? OK, it "includes the essential features and is easy to build from source and to integrate with an application", but why not just build the whole source package? Just compile Qt and copy the libraries you need (eg QtCore, QtNetwork, QtGui) when packaging your application. I did it in an hour with this command:

./configure \ -release \ -no-opengl \ -device linux-arm-generic-g++ \ -device-option CROSS_COMPILE=/usr/local/xcompiler/usr/bin/arm-buildroot-linux-gnueabi- \ -prefix /usr/local/qt512arm \ -opensource -confirm-license \ -make libs \ -nomake tools \ -nomake tests \ -nomake examples \ -skip qtwebengine \ -skip qt3d \ -skip qtandroidextras \ -skip qtcanvas3d \ -skip qtcharts \ -skip qtconnectivity \ -skip qtdatavis3d

vs. "lua build.lua ../LeanQt -P HAVE_WIDGETS"

and nothing significant has happended to the selected "essential features" subset of Qt since 5.6.

I beg to differ, there are a lot of small fixes all around which really add up

Also LeanQt has and continues to have "a lot of small fixes"; even backported features.

How do Linux distros handle Qt not releasing updates anymore? Do they basically fork it?

Qt still does release update for the Qt6 serie. Qt5 is basically discontinued even for commercial users and KDE has a collection of patches from Qt6 which also applied for Qt5 here: https://invent.kde.org/qt/qt/ which most distributions are using.

Qt absolutely releases updates

https://wiki.qt.io/QtReleasing

(Disclaimer: I work for the Qt company)

6.0.4 released at 2021-04-22, 6.1 released at 2021-04-27. Where's 6.0.5 and so on? It's not released. Debian supports its releases for 5 years, not for 5 days.

Debian supports its releases for 5 years, not for 5 days.

Only run Debian here, but to be clear, Debian supports releases for 1 year after the next release, so typically 3 years max.

Debian LTS is handled by a third party, non-debian org, via donations. All packages are not necessarily covered, it's not the Debian securtiy team.

This is important to understand, as LTS depends upon donations to decide what gets secuirty updates. Donors have a say. So for example, you'll see apache, openssl, php updated, but not obscure pacakges.

6.0 wasn't LTS afaict. 6.2 and 6.5 are LTS, but they still seem to only have 1-2 years of support

AFAIK LTS is for paying customers only. For mortal people there's no LTS, there're only promises that 6.3 is backwards-compatible (but then why people pay for LTS at all).

Qt 6.2.4 was released at 2022-02-17 and it's the last public available 6.2 version. 6.3 was released at 2022-03-16. For paying customers they released 6.2.8 few months ago, for example, but it's not available for everyone else.

Do you expect them to maintain all old releases for free forever?

I do not expect anything from them and I’m grateful to receive quality open source library for free with current terms as that’s infinitely better than having a proprietary library. I’m just merely trying to understand how Debian deals with thus situation.

That said, of course having upstream patches available for free, as it was in the past, would even be better.

I see. Thanks for clarification

6.0.0 was released 08.12.2020, with 6.0.4 released at 04.05.2021 as the last patch release in that minor series. That's more than 5 days of support for the 6.0 minor series.

If Debian supports its releases for longer than the upstream projects do, then that's a (perfectly valid) choice of Debian, but I'm assuming that involves maintaining those projects as well, to the standards of Debian's support policies.

I'm not sure if I'm understanding your question properly, but versions 6.2 through 6.5 are available here.

https://mirrors.ocf.berkeley.edu/qt/official_releases/qt/

You can find a more local mirror on the mirror list

https://download.qt.io/static/mirrorlist/

Tangential question but does anyone use QT for mobile?

How is it Qt 6 when qtcreator is still version 4.14? I think I don't understand Qt's versioning.

Qt Creator is 9.0.2 in bookworm [0] (and 10.0 in experimental [1]).

[0] https://packages.debian.org/bookworm/qtcreator

[1] https://packages.debian.org/experimental/qtcreator

Even worse with https://github.com/rochus-keller/leancreator/ which doesn't have any version at all ;-)

Qt is a C++ (and I guess Python) framework to write cross-platform applications.

Qt Creator is a C/C++ IDE that happens to be written in Qt, and has some extra features that make developing Qt easier, such as a GUI designer for your app's windows. But it's just an IDE, you can use it to write pure C or C++, even in a basic Makefile project, without ever touching Qt, those features appear only when you select a Qt project template. They have a whole bunch of templates.

They are separate things so there's no reason why the version numbers should be kept in sync. Qt Creator could be using an obsolete Qt 3.0 from decades ago, and it wouldn't matter, that's up to the Creator devs and would have zero effect on your experience as an end-user.

If you're a C or C++ user I recommend you try out Creator even if you have zero interest in Qt. I like how fast and responsive it is, the advantage of being written in a native language I guess.

Reply on news.ycombinator.com