Adventures in Debian's Qt Land

(perezmeyer.com.ar)

77 points | by jandeboevrie 294 days ago

6 comments

  • pjmlp 293 days ago
    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!"

    • jchw 293 days ago
      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.

      • rubymamis 293 days ago
        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.

        • jchw 293 days ago
          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.

      • hermitcrab 293 days ago
        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.

      • rumey 293 days ago
        > 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.

      • fluoridation 293 days ago
        >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.

        • jchw 293 days ago
          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.
          • vbarrielle 293 days ago
            I've considered doing that, was it hard to set up?
            • jchw 293 days ago
              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.)

    • ptx 293 days ago
      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,
      • sho_hn 293 days ago
        > 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.

      • seba_dos1 293 days ago
        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.
      • ducktective 293 days ago
        >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.

        • formerly_proven 293 days ago
          (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.)
          • ducktective 293 days ago
            >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.

      • dotti 293 days ago
        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.

  • Rochus 293 days ago
    I made myself independent of the "Adventures in Qt Land" by switching to https://github.com/rochus-keller/LeanQt.
    • gettodachoppa 293 days ago
      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

      • Rochus 293 days ago
        vs. "lua build.lua ../LeanQt -P HAVE_WIDGETS"

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

        • jcelerier 293 days ago
          I beg to differ, there are a lot of small fixes all around which really add up
          • Rochus 293 days ago
            Also LeanQt has and continues to have "a lot of small fixes"; even backported features.
  • vbezhenar 293 days ago
    How do Linux distros handle Qt not releasing updates anymore? Do they basically fork it?
    • torarnv 293 days ago
      Qt absolutely releases updates

      https://wiki.qt.io/QtReleasing

      (Disclaimer: I work for the Qt company)

      • vbezhenar 293 days ago
        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.
        • bbarnett 293 days ago
          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.

        • rprospero 293 days ago
          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/

        • torarnv 293 days ago
          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.

        • yellow_lead 293 days ago
          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
          • vbezhenar 293 days ago
            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.

            • nairboon 293 days ago
              Do you expect them to maintain all old releases for free forever?
              • vbezhenar 293 days ago
                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.

            • yellow_lead 292 days ago
              I see. Thanks for clarification
    • ognarb 293 days ago
      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.
  • zengid 293 days ago
    Tangential question but does anyone use QT for mobile?
  • LorenaMrtina 293 days ago
    [dead]
  • classified 293 days ago
    How is it Qt 6 when qtcreator is still version 4.14? I think I don't understand Qt's versioning.
    • gettodachoppa 292 days ago
      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.

    • layer8 293 days ago
      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

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