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&#x27;t we still not easily change caret&#x2F;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 (<a href="https:&#x2F;&#x2F;github.com&#x2F;nuttyartist&#x2F;notes&#x2F;pull&#x2F;574">https:&#x2F;&#x2F;github.com&#x2F;nuttyartist&#x2F;notes&#x2F;pull&#x2F;574</a>). I&#x27;m planning to continue transition from QWidgets to QML&#x2F;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 <a href="https:&#x2F;&#x2F;github.com&#x2F;miurahr&#x2F;aqtinstall">https:&#x2F;&#x2F;github.com&#x2F;miurahr&#x2F;aqtinstall</a> that allows you to easily download prebuilt Qt binaries. I hope they can revert their approach on that.

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.

&gt; 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&#x2F;year. That&#x27;s a very hard pill to swallow.

&gt;Today if I use Qt I don&#x27;t bother with the official SDK on any platform, as it&#x27;s not really worth it. Like, what, do I need to pipe my Qt account credentials into CI? No thanks, I&#x27;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&#x27;t even touch PATH.

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&#x27;t really like. I do understand that it&#x27;s not literally just to cause harm or out of greed. I&#x27;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 &quot;cloud&quot; 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&#x27;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&#x27;s difficult. From a pragmatic standpoint, it&#x27;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 &quot;ugly&quot; or &quot;janky&quot;, but as in, it literally does not work, you can&#x27;t redock widgets in most cases. Is it because they literally don&#x27;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&#x27;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&#x27;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&#x27;s far more mature and full-featured than most other toolkits that are open source, but that&#x27;s not exactly something to brag about either.Today if I use Qt I don&#x27;t bother with the official SDK on any platform, as it&#x27;s not really worth it. Like, what, do I need to pipe my Qt account credentials into CI? No thanks, I&#x27;ll build it myself.

&gt; Which point of criticism is this meant to address? In a normal open source project they wouldn&#x27;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&#x27;s packagers mailing list, and so do many others.If you don&#x27;t it that way, dumb things happen like distros releasing RC tags as &quot;we have the release now&quot; so they can announce same-day availability, and occasionally bugs slip through. Been there, done that.You probably understood this as &quot;normally you could just look at the git repo&quot;, but that&#x27;s also true for Qt 6.

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.

&gt;Which point of criticism is this meant to address?That they don&#x27;t release updates for Qt6 anymore (they did)Yeah, I&#x27;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&#x27;s pretty much it. I mean unless Elon gonna chip in and pay for development of it, we can&#x27;t expect competent people work on an alternative to these giants for free.

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.

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

To note for the usual Qt bashers:&quot;Thanks to The Qt Company and ICS the current Qt 6 version, 6.4.2, is also available as Bullseye&#x27;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!&quot;

vs. &quot;lua build.lua ..&#x2F;LeanQt -P HAVE_WIDGETS&quot;and nothing significant has happended to the selected &quot;essential features&quot; subset of Qt since 5.6.

I read the README and I really don&#x27;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 &quot;includes the essential features and is easy to build from source and to integrate with an application&quot;, 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:.&#x2F;configure \
 -release \
 -no-opengl \
 -device linux-arm-generic-g++ \
 -device-option CROSS_COMPILE=&#x2F;usr&#x2F;local&#x2F;xcompiler&#x2F;usr&#x2F;bin&#x2F;arm-buildroot-linux-gnueabi- \
 -prefix &#x2F;usr&#x2F;local&#x2F;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

I made myself independent of the &quot;Adventures in Qt Land&quot; by switching to <a href="https:&#x2F;&#x2F;github.com&#x2F;rochus-keller&#x2F;LeanQt">https:&#x2F;&#x2F;github.com&#x2F;rochus-keller&#x2F;LeanQt</a>.

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

Qt absolutely releases updates<a href="https:&#x2F;&#x2F;wiki.qt.io&#x2F;QtReleasing" rel="nofollow">https:&#x2F;&#x2F;wiki.qt.io&#x2F;QtReleasing</a>(Disclaimer: I work for the Qt company)

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: <a href="https:&#x2F;&#x2F;invent.kde.org&#x2F;qt&#x2F;qt&#x2F;" rel="nofollow">https:&#x2F;&#x2F;invent.kde.org&#x2F;qt&#x2F;qt&#x2F;</a> which most distributions are using.

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

Tangential question but does anyone use QT for mobile?

Qt is a C++ (and I guess Python) framework to write cross-platform applications.Qt Creator is a C&#x2F;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&#x27;s windows. But it&#x27;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&#x27;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&#x27;t matter, that&#x27;s up to the Creator devs and would have zero effect on your experience as an end-user.If you&#x27;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.

Qt Creator is 9.0.2 in bookworm [0] (and 10.0 in experimental [1]).[0] <a href="https:&#x2F;&#x2F;packages.debian.org&#x2F;bookworm&#x2F;qtcreator" rel="nofollow">https:&#x2F;&#x2F;packages.debian.org&#x2F;bookworm&#x2F;qtcreator</a>[1] <a href="https:&#x2F;&#x2F;packages.debian.org&#x2F;experimental&#x2F;qtcreator" rel="nofollow">https:&#x2F;&#x2F;packages.debian.org&#x2F;experimental&#x2F;qtcreator</a>

Even worse with <a href="https:&#x2F;&#x2F;github.com&#x2F;rochus-keller&#x2F;leancreator&#x2F;">https:&#x2F;&#x2F;github.com&#x2F;rochus-keller&#x2F;leancreator&#x2F;</a> which doesn&#x27;t have any version at all ;-)

How is it Qt 6 when qtcreator is still version 4.14? I think I don&#x27;t understand Qt&#x27;s versioning.

Adventures in Debian's Qt Land