hannofcart a year ago

Glad to see the update. Most people associate Qt with GUIs which is unfortunate.

I see that when people think of Qt, they think of WxWidgets, Cocoa or MFC as alternatives. No, I submit to you that Qt framework is a more elegant, easier to use alternative to Boost as well.

This is not to say that QtQuick or QtWidgets aren't solid. However, the success of these two modules ends up occluding the others which to me are the real gems from the QtFramework: QtCore and QtNetwork.

QtCore provides a solid event loop, the most easy to use implementation of the observer pattern via its signal-slot mechanism, robust threading utilities and a bunch of other utilities that make writing apps in C++ an absolute breeze.

QtNetwork for a series of networking utilities that are elegantly simple.

If I were to write a command line app or a database or server, I'd reach for Qt in a jiffy.

Qt is not just for GUIs!

  • Jasper_ a year ago

    I really wish QtNetwork was better. I recently went and had to replace QtNetwork with our own event loop because it is extremely unreliable on Windows. The only mention of this is a footnote in the API docs:


    • justinclift a year ago

      Yeah. It also turns out that just having a Qt application running on a computer can tank network latency for all applications on the computer:


      There is a workaround, but developers have to know about it first. And it's such an unexpected and weird behaviour that 99% of developers don't.

      This was our fix (1 line of code), in case that helps anyone:


      • nly a year ago

        Yup, i work on software with a Qt GUI and it took us ages to figure out why our daemon (no Qt dependencies) would experience latency when the GUI was open.

        For Windows users we now put this var in to global environment via our installer, and probably break other software in the process.

        • justinclift a year ago

          > ... and probably break other software in the process.

          You might also be fixing it for some too, if they're running other Qt applications. :)

    • ambrop7 a year ago

      Why would you use waitForBytesWritten if you want an event loop? Just do as the note says.

  • makmanalp a year ago

    Also the image/video stuff and the browser, all the stuff that's /so/ insanely annoying to make cross platform works without a hitch.

    • j_s a year ago

      Is there a quick link to supported media formats? I will see if I can find it.

      It looks like (as of early 2016 at least) it is platform-dependent, which makes sense but kind of takes away the appeal for me.



      • makmanalp a year ago

        Er, sorry, yes, the video /formats/ are unfortunately defined by the available media encoder backends, but it's more that I don't have to write any platform or media backend specific code to e.g. show video from a webcam, have a video player control, or record and save audio, etc etc. So your code remains the same, all you need to do is bundle codecs when shipping, or make sure you use formats that the default media backends of most platforms support.

        This might help: https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends

        If you get a format that all of Directshow(win), AV Foundation(osx) and Gstreamer(linux) support, you're pretty much set. Something like mp4 container with h.264 video and mp3 audio is pretty standard these days.

  • lossolo a year ago

    > or a database

    This is not the best example. Qt has a lot of overhead in its event loop, threading, parallelism and containers implementations compared to alternatives. It's not the best choice as a base for high performance database.

dazzawazza a year ago

I've coded desktop apps (mostly editors and tools for games) for 25 years across X (Motif toolkit), Amiga, TOS, DOS, MFC, Cocoa, Win32, WxWidgets, Fox Toolkit and Qt. Qt has by far been the best, most rewarding, most empowering experience. It's a great library.

Now Cocoa would win but I prefer C/C++ to Objective-C, it's close though.

Good work people.

  • problems a year ago

    It really is - any many people focus on its features as a GUI library, but it goes so much beyond that. Providing data structures, concurrency primitives, file management, networking, high performance drawing, etc. And it provides all these in a cross platform way that often feels nicer than other C++ libraries in my experience. Sometimes these are less robust than alternatives, but often they're much more elegant.

    • pjmlp a year ago

      > And it provides all these in a cross platform way that often feels nicer than other C++ libraries in my experience.

      It follows the path of Turbo Vision, OWL and VCL.

      Where productivity comes first, and C style tricks are only done when performance really matters.

      Many C++ APIs suffered from std not being rich enough, and lots of Cisms in the early days.

      Nowadays with all major OS vendors switching to safer languages for the UI layer, Qt seems to be the last C++ GUI framework in widespread usage.

    • justinclift a year ago

      Qt's file management seems extremely poor though. It's not even possible to set the last modified date/time on a file through Qt. :(

      • user5994461 a year ago

        Poor compared to what?

        The stdlib doesn't have anything to use files.

        The C win32 API CreateFile() has 6 arguments each more obscure than the previous one. Gotta support sync and async in a single function.

        The C kernel API NtCreateFile() has around 13 arguments, probably including enum with 105 different values.

        • justinclift a year ago

          Well, Qt provides a QFile class to do standard file operations. eg create, remove, rename, etc.

          It also has the QFileInfo class to retrieve file info, such as creation/last-modified/last-accessed date.

          It just seems super weird to not also have the matching functions available to set those dates. Which we really wanted for our client side Qt/C++ GUI, as I'd just finished doing the server side part in Go which does provide those.

          And Qt seems to provide pretty much everything else... but this one weird bit which is missing. :/

    • nly a year ago

      To be honest I find everything outside of the GUI subset really really poor. Plus the fact you can basically never escape callback soup, and it's really hard to integrate the Qt event loop in to anything else.

      QML, Quick and Qt Widgets are fantastic though.

  • arca_vorago a year ago

    I'm very interested to hear your opinion on WxWidgets, as I have heard more desktop app devs endorse it over the years. What features makes QT win out over it?

    Also, I know this might sound crazy, but what about (f/m)asm?

    • 72deluxe a year ago

      Not sure on Qt's features as I last used it in the KDE 3.5 days for basic basic apps, but I have used wxWidgets extensively. The Mac port has improved significantly recently, although there are still bugs.

      It uses the native UI so fits in better with OSes, whereas Qt ones stand out to me (you can see the buttons aren't native). I did a lot of stuff that was "owner drawn" so reimplemented OnPaint to draw things myself for custom-look controls.

      wxWidgets dropped its ODBC support a few years back so talking to databases likely needs another library. Also the ports/HTTP section of it isn't massively useful so I use libCurl instead.

      Despite the bugs, it is quick to build and I found working with it enjoyable. Some controls (like the wxDataViewCtrl I think) were really slow so I wrote my own; the OpenGL wrapper works alright but I had to put some work into forcing it to resize; basically be prepared to put some work in - but it is rewarding. I like the layout mechanism - makes other systems like MFC look poor!

      You can build wxWidgets and force it to use the STL for its container classes etc; Qt appears to implement everything again instead of just using the existing STL I think.

      The developers are helpful and the forum is useful, at least for basic problems. I enjoy(ed) using it anyway.

    • tonyedgecombe a year ago

      I used wxWidgets for a couple of applications, the core was OK but anything outside of the basic widgets tended to be buggy. I wouldn't use it again.

    • dazzawazza a year ago

      It was so long ago that I used WxWidgets I'm not sure my opinion has value any more. Certainly 10 years ago it suffered from poor documentation (like most open source projects) but the Python bindings were very nice. Also Qt has a nice interface builder (not as nice as Cocoa but very useful) WxWidgets didn't have one at the time.

      I don't know what (f/m)asm is in this context, sorry.

    • gcp a year ago

      wxWidgets wins because of native widgets, a handier license, and no moc etc requirements.

      I think Qt wins in all other domains though. Documentation, extensiveness and quality of the non-GUI stuff, etc.

      But not having native widgets kinda sucks. You can see that when you make that compromise, the question comes why not to use Electron (which is a competitor of those two in reality).

  • musage a year ago

    Do you know Magic User Interface (MUI) for the Amiga? I only know it as a user, but I still miss it.

    • dazzawazza a year ago

      Ha no, I did Amiga application in 68K assembly language. MUI looks very modern compared to my Amiga experience :)

      I still miss the Amiga in general though. It was nice to have complete control over the machine, working in harmony with the OS... or hosing it and causing a Guru Meditation.

      • baldfat a year ago

        > Guru Meditation

        I caused so many of those, lol. It is also funny how I gravitated to Linux and Qt after finally leaving Amiga. Qt back than seemed like a combination of Amiga and BeOS.

        Side note:

        The funny thing is I think the computers of the future will more resemble the hardware structure of the Amiga than the single chip multi-core computers of today. Once we can't fabricate smaller nor make faster calculations the module design we had of the amiga will become dominate. We are on the edge of having a CUDA built on the silicone or what Power9 is doing by giving them faster lanes.

      • musage a year ago

        Yes, it was modern, it maybe still is. Doesn't really care about resolution or window size, with crazy detailed system-wide configurability; set it up once, and all apps that use it look exactly like you want them to. I don't know much about GUI toolkits, other than that most apps don't resize much other than lists and seem very limited that way compared to even basic MUI applications, but I think that MUI kind of puts the modern web and "user agents" to shame, especially if you consider how old it is.

      • greggirwin a year ago

        Someone mentioned Red in a comment here. Coincidentally, it's a descendant of Rebol, which was designed by Carl Sassenrath, architect of the AmigaOS.

  • shmerl a year ago

    Cocoa is not cross platform, so it's not a competitor.

    • polpo a year ago

      Well, there's GNUstep... I'd be interested in knowing if anyone has used it recently and how complete it is.

      • pjmlp a year ago

        It is dead, last time I checked they were still trying to reach parity with Panther.

        • mattl a year ago

          Not dead at all. Microsoft has been using it to bring Obj-C to Windows. https://github.com/Microsoft/WinObjC

          • pjmlp a year ago

            I thought WinObjC died alongside the Windows Phone efforts, and I do Windows development.

    • saosebastiao a year ago

      It's a UI Toolkit, so it is a competitor. Just one with a less compelling feature.

    • mattl a year ago


  • Razengan a year ago

    What about Cocoa with Swift?

    • dazzawazza a year ago

      I've not used swift yet but it looks very nice. Cocoa is still a very well designed and complete toolkit so I imagine it would be very productive.

mherrmann a year ago

I'm an indie dev and have been developing a cross-platform (Py)Qt app for the past 1.5 years (~2100 dev hrs) [0]. Given that Qt is cross-platform desktop development, it's very solid. But there are a lot of things one has to do that are not required for (say) web apps:

* Creating standalone executables / installers for the app itself is already not so easy (I use - and recommend - PyInstaller [1]).

* Code signing the executables so users don't get an ugly "this app is untrusted" warning is tedious for the three different platforms

* Auto-updating is a pain to implement as well. I'm using Google Omaha (same as Chrome) on Windows [2], Sparkle on Mac [3] and Debian packages / fpm on Linux [4]. In total, I probably spent two to three months just on auto-update functionality.

* You really can tell that Qt is "drawing pixels on screen". Sometimes you have to draw pixels / perform pixel calculations yourself. The built-in "CSS" engine QSS works to some extent, but often has unpredictable results and weird edge cases.

I considered Electron as well. But its startup performance is just prohibitive. I blogged about this (and which other technologies I considered) [5].

I've been wondering for a while whether I should not open source my solutions to all of the above problems, to save other people the months required getting everything to work. Would anybody be interested in that? It would be something like a PyQt alternative for Electron.

[edit] People are very interested so I'm starting a MailChimp list. If you want to know if/when I open source a solution then please subscribe at http://eepurl.com/ddgpnf.

[0]: https://fman.io

[1]: http://www.pyinstaller.org

[2]: https://fman.io/blog/google-omaha-tutorial/

[3]: https://sparkle-project.org/

[4]: https://github.com/jordansissel/fpm

[5]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...

  • evsasse a year ago

    Wow, never felt so connected to a hn reply. This is so similar to my experiences using PyQt, so it probably describes the experience of a lot of other devs out there.

    We made a MVP using Electron but had to ditch it because of performance issues. PyQt seems like the best alternative, but the pain points you described were hard obstacles in the beginning.

    * We gave up on making Omaha work, after some wasted weeks, and are using pywinsparkle to autoupdate on windows.

    * The QSS feels buggy all around, the "border-radius" property is one of the simplest examples of that.

    Would greatly appreciate some open-source solutions, examples or simply some blog posts of best-practices and how you are managing these pain points. :)

  • baldfat a year ago

    > Creating standalone executables / installers

    Python's Achilles heel, this is what caused me to walk away from Python. I usually make short very specific programs and I work on multiple of sites. Python was a pain to make executables. I now try to use Racket for everything and it makes executableson Windows, Linux and Mac.

    Has things really improved the last 2 years?

    • zbentley a year ago

      I've seen people use Docker for this purpose, even on Mac/Windows. Personally, that seems a bit like using a howitzer where a flyswatter will do, especially since a lot of performance gains are going to be negated by Docker's virtualization on Mac and Windows.

    • nly a year ago

      It's not a python specific problem. I work on a native app on 3 platforms and have had the same distribution pains.

  • vram22 a year ago

    I'm interested, and signed up. Thanks for offering to do this.

    Just as anecdata, I've tried out Qt w/C++ a bit earlier and what I tried, I found good. And I wrote some simple wxPython GUI wrappers for my xtopdf toolkit, that experience was good too.

    I've also tried out PyInstaller a bit for both simple CLI and GUI (wxPython again) apps; that worked well too. It's an interesting piece of technology; I think it must be doing a lot of stuff.

  • user5994461 a year ago

    Qt apps are easy to ship. It's just copying a bunch of files. For windows, you can create an installer with InnoSetup, it's super easy.

    I suppose the issue is distributing python.

  • Siecje a year ago

    I would be interested in your packaging and auto updating solution.

  • aeroxis a year ago

    I evaluated Qt for one of my personal side projects and ended up going to electron for the reasons you mentioned. Electron, while simple to use, feels slow to launch and run on someone with hardware that is a few years older.

    • rasjani a year ago

      Are electron binaries somehow pre-signed?

  • panta a year ago

    Thanks for fman and for the transparency of your whole process. I am decidedly interested in your open-sourcing fman, I'll add myself to the subscription list. I have a suggestion: why don't you launch a kickstarter (or other more suitable campaign) to collect a fund acting as a payment for the open-sourcing of fman. That could compensate you for the tremendous effort that went in the development till now.

    • mherrmann a year ago

      I don't think I'd really get a lot of money on Kickstarter. if people want to financially support the project, they can simply get a license [0].

      [0]: https://fman.io/buy

      • panta a year ago

        Yeah, I think I was one of the early licenses, but I was wondering if there was a way to open source it while preserving the financial benefits.

Koshkin a year ago

As good as QT and KDE are, I cannot really explain the fact that the most popular Linux distributions seem to show preference for Gnome; is Gnome more stable? is the user experience provided by Gnome more "polished"? or, is it the K-isms that push them away? is Gnome less resource-hungry?

  • octorian a year ago

    While the official story is that it was a political issue (or "licensing hissy-fit" depending on your point of view), I often can't help but wonder if that was really somewhat of a cover for a bunch of stuck up C developers who simply hated C++.

    Of course the one time I attempted to write something with Gtk+, it very much felt like a "We hate C++, so we're going to implement everything C++ does as conventions and macros on top of C" project.

    In the early days, Linux/gcc also had some dynamic linking performance issues with complex C++ libraries. As a result, KDE apps actually did take a lot longer to start up than Gnome apps. However, once launched, the KDE stuff always felt like it actually ran faster. Thankfully those issues are long since fixed.

    • blattimwind a year ago

      KDE is mostly developed by Europeans (Qt as well), Gnome (and GTK) mostly by Americans, though this has somewhat diminished over the years. The Gnome Foundation is registered in California, while KDE e.V. is a German non-profit.

      KDE, in a sense, was the original free desktop.

      > K Desktop Environment (KDE) was founded in 1996 by Matthias Ettrich, who was then a student at the Eberhard Karls University of Tübingen. At the time, he was troubled by certain aspects of the Unix desktop. Among his concerns was that none of the applications looked, felt, or worked alike. He proposed the creation of not merely a set of applications but a desktop environment in which users could expect things to look, feel, and work consistently. He also wanted to make this desktop easy to use; one of his complaints about desktop applications of the time was that it is too complicated for end user.

      Gnome could be considered an American "but-its-not-all-under-my-gpl" response.

      Personally I always found glib and friends always quite ugly from a technical standpoint, and the poor documentation and support for platforms other than Linux made me move to Qt quite early on when I started.

      • digi_owl a year ago

        Dunno about KDE, as i can't say i have followed it much since the whole KDE4 mess. But Gnome/GTK is looking more and more Anglo-germanic, and not in a good way...

        • flukus a year ago

          > But Gnome/GTK is looking more and more Anglo-germanic, and not in a good way

          That's weird, AFAIK KDE development is predominately German, Scandinavian and Anglo and I was under the impression that many key gnome developers were South American.

      • Fnoord a year ago

        Qt has always been available under a dual license. A commercial one, and... "one intended to be open source". If you wanted to make your application open source you could use Qt, and if you wanted to keep your application proprietary you could buy a commercial Qt license.

        Back when KDE was being developed (which was open source), although the Qt source was available Qt wasn't free software nor OSI compatible. Back then it was owned and developed by Trolltech ASA, a Norwegian company (it was eventually bought by Nokia). Because it wasn't considered free software nor OSI compatible, certain distributions such as Debian didn't include it in their free repository and the FSF claimed it was incompatible with the GPL. So you had to grab it from non-free. I remember compiling 1.4x myself, same with KDE. It was eventually released under the QPL which wasn't considered GPL compatible by the FSF. Eventually it was also released under the LGPL. However while all this relicensing was going on (and it took various years), GNOME was already being developed, which was taken under the wing of the FSF as the free software desktop. By the time Trolltech had released Qt under the QPL and GPL, we already had a fractured "Linux" or open source desktop.

        During the early versions of GNOME and KDE (before Web 2.0) ie. KDE 1, KDE 2, KDE 3 and GNOME 1 and GNOME 2 KDE was seen as a Windows esque desktop environment with lots of bells and whistles. As you say, it had large support in Germany and SuSE. Meanwhile, GNOME was regarded as a more Apple-esque desktop environment (like OSX or macOS as its called now) and the other main large commercial Linux distribution RedHat and main competitor of SuSE had GNOME as default desktop environment. GNOME also had HIG when KDE didn't yet.

        Meanwhile, as you put, GNOME's libraries were LGPL and were therefore more proprietary-friendly because it doesn't require the fee for a commercial license which Qt has. For bigger companies that might not be a large barrier of entry, and you can find an ample amount of high commercial quality applications based on Qt.

        A comprehensive history is written on Wikipedia [1]

        Incomplete lists of software using Qt (doesn't contain discontinued software such as e.g. Opera for Linux) [2] [3]

        [1] https://en.wikipedia.org/wiki/Qt_(software)#History_of_Qt

        [2] https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...

        [3] https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt

    • AceJohnny2 a year ago

      > Of course the one time I attempted to write something with Gtk+, it very much felt like a "We hate C++, so we're going to implement everything C++ does as conventions and macros on top of C" project.

      The original reason for that was ABI compatibility, and being able to provide bindings for various languages which was considered a primary goal. As I recall at the time, there was no C++ ABI standard (or GCC didn't implement it), and it was considered hard to provide bindings of the library to various other languages.

      GTK was written in C mainly for that reason.

      This also explains why common object-oriented concepts are reimplemented in C in GTK, because them rejecting C++ for ABI reasons didn't mean they rejected the concepts.

      This also explains Vala, Gnome's OO language that pre-processes to C, in order to get the best of both worlds. (anyone getting CFront flashbacks?)

      History puts everything in context...

      • foldr a year ago

        Writing bindings for Qt is still a major undertaking compared to writing bindings for Gtk. There are okish gtk bindings for lots of languages, but Qt bindings are only available for massively popular languages.

      • user5994461 a year ago

        There isn't and has never been a standard C++ ABI. To interface with a C++ dll, you need to compile the executable with the same compiler version and the same flags.

        • AceJohnny2 a year ago

          You're right, it turns out what I was thinking of was just the Name Mangling convention, which looks like it isn't standardized either.

          • user5994461 a year ago

            The name mangling is part of the ABI. It's super complicated in C++ because the functions can be overloaded and have variable amount of arguments. The rules are compiler and version and flags specific.

            P.S. Name mangling is what define that the function "int print(char*)" will become "___4print@4" in the compiled DLL. All the functions in a DLL are listable and have a name, that's how they are found.

    • digi_owl a year ago

      A bit of A, a bit of B, a bit of C.

      It was a "Look at me!!!" project by De Icaza, the same guy that would later do Mono and now works for Microsoft, using the Gimp derived GTK toolkit, and using the Qt license as a pretense.

      Looking back at it, it is really "funny" how much alike the path of Icaza and Poettering is.

    • pjmlp a year ago

      > Of course the one time I attempted to write something with Gtk+, it very much felt like a "We hate C++, so we're going to implement everything C++ does as conventions and macros on top of C" project.

      As I replied in a sibling comment, yep that was part of the issue.

  • wenc a year ago

    It started out as a political issue (KDE being dependent on Qt, and Qt not being GPL at the time). The history is here: https://www.kde.org/community/history/qtissue.php

    I've always preferred KDE to GNOME because I feel it is higher quality desktop environment, but I will be the first to acknowledge KDE mucked up around KDE 4 and even today there are weird glitches in the vastly improved KDE5. That said, I still run Kubuntu because I feel it continues to be better than Ubuntu (GNOME), and I can live with the little annoyances.

    • whateveruser a year ago

      Could also be that Red Hat has a lot of devs on Gnome. That means more contributions, which means greater control over project's direction, the only way that can happen in OSS. And with corporate backing comes faith from many people. Also Debian defaulted to Gnome since v1(?). So did Ubuntu(mostly). KDE is very much a community project despite considerable resources from SUSE and few other corporate entities. Add to it Gnome's almost fixed 6 month churn and it becomes a pretty enticing choice for organizations having to support that piece of software for 5+ years.

      • digi_owl a year ago

        And you will also find that while KDE devs stay without their on sphere for the most part, Gnome devs "dives the stack".

        Meaning that you will just as often find them working on something under the Freedesktop banner, but with a massive Gnome slant, as on Gnome proper.

        In other words while KDE devs have a clear understanding of where the DE ends and the rest of the OS begins, Gnome devs seems to consider everything above the kernel (and is likely biding their time for the day Torvalds steps down) the domain of Gnome.

      • blattimwind a year ago

        Debian was initially released before either Linux desktop.

        • whateveruser a year ago

          Hence the question mark. What did Debian have for v1 then?

    • vram22 a year ago

      What Kubuntu version do you use? I've had the same thoughts as you about KDE vs. GNOME in the past (at earlier versions though, don't know about how they stack up currently).

      • wenc a year ago

        I run Kubuntu 16.04 LTS.

        • vram22 a year ago

          Thanks for the info.

          • shaan7 a year ago

            I use KDE Neon, it has the latest Ubuntu LTS as base but with latest KDE. See http://neon.kde.org/

            • vram22 a year ago

              Just saw this now. Thanks, will check it.

  • Santosh83 a year ago

    Several reasons. Many years back a lot of distros chose to default to Gnome because of licensing doubts/FUD surrounding Qt. That decision's momentum still continues, the result being that Gnome remains default, if for no reason than to not to undergo a big shift in defaults. Secondly the ripple effects from a few major distros adopting Gnome is more pervasive than we imagine. Two of the largest, RedHat and Debian, have long used Gnome as their default desktop. And in RedHat's case, they actively contribute to and fund Gnome development. A huge number of derivative/downstream distros either go with these stock choices or have chosen to implement their own "shells" around the GTK/Gnome base. One reason for this was the historical requirement to stick to C++ for extending or modifying KDE; in Gnome's case the language support is wider when developing for it, or taking its components and building on top of it, like Cinnamon and Budgie have done. Gnome and GTK were advocated by orgs like the FSF, which has done a lot to popularise their mindshare among FOSS developers. Historically (no longer the case but momentum once established...) Gnome was also lighter on system requirements and the DE was split into small modules which could be adapted into other indie DEs. This was more difficult with KDE previously.

    Am sure there are more subtle reasons. But recently there's a noticeable swing towards Qt. The next version of Budgie will build upon Qt, as did the aborted Unity8. LxQt is the future LXDE. But GTK has an entrenched mindshare in FOSS that Qt just doesn't.

  • pjmlp a year ago

    It goes back to the C vs C++ war, and to the old issues with Qt license.

    So not only there was the license issue, usually C devs would side with Gtk+/GNOME and C++ with Qt/KDE.

    I remember a few language flame wars when Gtk--/Gnome-- were started, nowadays Gtkmm/Gnomemm.

    Back in the day SuSE and Mandrake were the best KDE distributions for desktop users.

    As they kind of faded way, KDE lost a bit of momentum.

    Then there was the whole mis-understanding with their reboot, which was supposed to be dev only and distributions took it as if it was ready.

  • pfranz a year ago

    I keep hearing about all the cool, dynamic things you can do with KDE, but the Gnome UI looks more consistent and polished. KDE has just seemed thrown together. However, my needs are minimal. I spend all my time inside large applications or in the terminal. So I just need a simple window manager, terminal app, and occasionally a file browser. I was frustrated when Gnome paired down their UI.

    On the programming side (via Perl and Python), I never liked GTK and have always preferred Qt.

vram22 a year ago

Andy Brice has two successful desktop app products, Perfect Table Plan and HyperPlan [1], and both are written using C++ and Qt, IIRC; I read that on his blog [2], which I have been following for some time now. Lots of good info about product development and marketing there.

[1] At least, Perfect Table Plan is quite successful, he has been selling it for a long time now. HyperPlan is newer, but IIRC he had some sales for it too.

[2] https://successfulsoftware.net/

  • vram22 a year ago

    And seeing a few comments about toolkits being cross-platform, reminded me: his apps work on at least both Windows and Mac (not sure about Linux, but I do remember the Qt version I tried earlier works on Linux too).

b1gtuna a year ago

Is Qt a good, modern framework for desktop application development for a beginner? If not, can someone recommend something else?

  • dkersten a year ago

    Qt (and QML especially) is, in my opinion, the best way to do any modern-non-web UI work. Its built on a hardware accelerated scene-graph allowing for smooth compositing and animation, QML is an easy to use means of creating your UI and connecting it to C++ (especially post-C++11) is trivially easy allowing for good solid high performance UI's. You can also use Javascript if that's your thing, but for large applications (or iOS where its interpreted) you will need to take care to not run into performance issues. For small applications, its not a problem though.

    Additionally, QWidgets, the old pure-C++ based UI libraries are still available too. It also bundles a ton of other stuff, an embeddable web browser, javascript engine, collections library, concurrency library, networking library etc.

    • joshklein a year ago

      I do agree, but only if we emphasize the cross-platform requirement and a single monolithic code base.

      I’d much rather write a lightweight desktop app in any of the native toolkits, but especially Cocoa/Swift, and do the heavy lifting parts outside of the GUI application. But you’ll still have to write a native Linux one, and QT is my front runner there. But I do recommend looking at the Xamarin stuff too. Depends on your needs and where you’re coming from as a dev.

      • shmerl a year ago

        Writing many native UIs can be a waste of time, especially if you need to maintain and update them.

        • joshklein a year ago

          Yes, but writing a cross platform UI for a single platform use case is a waste of time as well.

          • gmueckl a year ago

            When you're stuck with C++, writing a GUI in anything but Qt on Windows or Linux is basically a waste of time. MFC on Windows sucks hard and Qt is simple the native go-to C++ toolkit for Linux.

          • shmerl a year ago

            It can make porting later to other platform easier. Using a lock-in on the other hand taxes any such future effort.

            • joshklein a year ago

              That’s why your use case matters. If we are going down this path of thinking with no context, your application should not be a GUI application at all. But if you want easier future porting to iOS, that’s different than if you want easier future porting to xbox, and different again if you want it to run on ChromeOS.

              QT is awesome, don’t hear me wrong. But if your target platform is distros running gnome, it might not even be the right choice for a native Linux desktop app. And again, none of this cross-platform compatibility discussion necessarily makes it a better choice than Xamarin stuff.

              I’m just saying, it’s not “the” option. It’s just a very good choice.

  • sevensor a year ago

    If you want to use QWidgets, I highly recommend PyQt for beginners. PyQt is a very well done set of Python bindings. With rare exceptions, the Qt behavior and docs map straight over. E.g. if a method takes a QString, you can send it a Python string and it just works. It's dual-licensed GPL, so you do have to pay for it if you're selling something, but it's worth supporting the small company that produces it.

    • tux1968 a year ago

      To be slightly pedantic, you are not required to pay for it just because you are selling something. The requirement is only that you comply with the terms of the GPL license by releasing source to any modifications that you ship.

      • ericfrederich a year ago

        ... or the source to any code that uses PyQt. Nobody knows. It hasn't been tested in court. I'm not sure it's even been tested with C code that links against a GPL library. With Python you're another step removed because it's dynamic and the linking doesn't happen until it's on the consumer's computer.

        Point is... it's a gray area.

        • belorn a year ago

          Thats how the law work. A copyright owner go to a judge and say "The accused sold work based on my copyright" and the accused has to bring up the GPL as proof that they have permission, or they argue that the new combined work do not include any copyright-protected elements of the original. Its a grey area by design.

          Linking technology itself is actually rather irrelevant to the legal questions that a court general ask in defining copyright. FSF happen use it as a bright line in the sand on where they will enforce the license, but any author can make their own decision on that matter. Game companies has for example gone after mods that inject itself through windows libraries, arguing that the mods purpose and existence is dependent on the original game and thus created a derivate work.

          There was a historical case when a person legally bought a painting and cut it into several pieces only to stitched them together into a mosaic. The court judged it as a derivate work and thus requiring additional copyright permission from the author.

          As with other gray areas in copyright, derivative work also have semi-exceptions. Compatibility is one. Since there is multiple different C standard libraries, it would be hard to argue that a program is specifically a derivative work of one. It would also be very easy to demonstrate the works independence by simply using a different standard library.

          PyQt brings a interesting question but in the end I doubt it would be that much of a gray area. In theory you could make a program that is only compatible with Qt but don't actually depend on it, but in practice I suspect most such program do not start, operate, and function if you remove the Qt parts. In such cases I expect the accused will have a hard time arguing that the final work when used has no copyright-protected elements of Qt.

      • vetinari a year ago

        To be slightly even more pedantic, it is GPL and not LGPL, so that would mean releasing sources to your app, not just to the modifications.

      • cpburns2009 a year ago

        But by it being GPL, you also have to release the source code of your potentially proprietary code as GPL. It's LGPL where you only have to release the modifications to the library.

        • dkersten a year ago

          > It's LGPL where you only have to release the modifications to the library.

          Even then, only if you dynamically link to the library.

          • jacoblambda a year ago

            don't you mean statically? I assumed dynamic linking was largely regarded as exempt from GPL

            • dkersten a year ago


              If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.

              If you dynamically link to an LGPL library, then only the library must be under an LGPL-compatible license (ie if you modify the library, those modifications must be made available), but your own code that links to the library can be under any license you wish.

              This is because the LGPL considers statically linking as a single work, while dynamic linking as multiple works, which can be licensed independently.


              Regardless of linkage, your code must be under a GPL compatible library.

              The GPL considers the software as a single work regardless of linkage.

              • jjnoakes a year ago

                > If you statically link to an LGPL library, then the entire codebase (your code and the library) must be covered under an LGPL compatible license.

                This isn't right. You can statically link proprietary code to LGPL libraries and the LGPL license does not "infect" your proprietary code.

                The only thing you have to do if you go this route is ensure that the people receiving your combined work are able to relink any modified version of the LGPL pieces. This can be done, for example, by providing object files for the proprietary pieces and a script to link them to the LGPL pieces, upon request.


    • Siecje a year ago

      You can use QML with PyQt5.

    • ericfrederich a year ago

      I'm not sure about the current state of PySide, but PySide is LGPL. Might want to look there too.

      • sevensor a year ago

        Last I checked, the original PySide had been more or less abandoned around the time Qt5 came out, and the Qt Company was at work on PySide2. We'll see what comes of it; I haven't heard any big announcements, and it doesn't seem like a priority.

  • skibz a year ago

    A sort-of left field suggestion would be to try Red [1]. I'm quite impressed with it, so far! However, I'm not sure how suitable it is considered to be for beginners.

    [1]: http://www.red-lang.org/

    • baldfat a year ago

      I would think Ring [1] would be a better fit int he comments since Ring has QT bindings. Ring and Red seem to have the same goal of making GUI programming easy. Personally the syntax of these languages drives my inner Lisp brain a little crazy.

      [1]: http://ring-lang.net/

  • pavlov a year ago

    It's a very good choice as long as you're comfortable with C++.

    • nabla9 a year ago

      What that is supposed to mean?

      Qt has language bindings.


      • pavlov a year ago

        Qt bindings seem very niche. I don't think I've ever seen a Qt project written in anything but C++ (or QML+JavaScript for simple apps).

        Maybe the bindings are good? I just don't know, and I'm suspicious of an approach that seems to be entirely outside of mainstream Qt practice.

        • gtaylor a year ago

          PyQt is very good

          • dkersten a year ago

            For QWidgets. If you want to use QtQuick, you're basically using javascript and/or C++ (I'm not personally complaining, I'm comfortable enough in C++). EDIT: seems there's rust bindings for QtQuick too.

            • Siecje a year ago

              You can use QML with PyQt5, instead of using C++ you use Python.

              Yes you still write QML.

              • dkersten a year ago

                I stand corrected. Thanks for letting me know!

            • jcelerier a year ago

              There are Rust, Go and D bindings to QtQuick afaik.

      • oblio a year ago

        Yeah, but can you use it for any serious application while knowing 0 C++?

    • Iwan-Zotow a year ago


      work great with Python

  • meirelles a year ago

    For sure, Qt is great even for CLI applications (if the dependency is not an issue).

    • gusmd a year ago

      Agreed! I use it at work for a CLI application that runs on an HPC environment.

      All the niceties that Qt as a framework provides (file system, multi-threading [mutexes, threads, semaphores, etc], JSON, shared memory, CLI arg parsing, even a State Machine!!) are a huge productivity boost.

      • geezerjay a year ago

        Where's the added value of Qt's support for multithreading when compared with the C++ standard support for multithreading? IIRC, Qt introduces the irrelevant QReadWriteLock and that's it. In fact, the only upside of Qt's multithreaded support is that they were developed to serve Qt's very particular needs.

        Qt is awesome but one of its main problems is its insistence of duplicating standard components and coming up with subpar alternatives which are then forced upon developers.

        • user5994461 a year ago

          >>> the C++ standard support for multithreading?

          30 years in the making, still waiting for that thing to actually exist.

          How long have you been developing in C++? The standard is so little, there might as well not be one. I don't even think the printf() function takes the same arguments on all platform.

        • gusmd a year ago

          Last year I went through Anthony William's C++ Concurrency in Action to better understand the "new" threading library. No complaints. Actually, I've been using it in several components that are "pure C++" (i.e., no Qt, only STL).

          My point of view is that, where I'm using Qt anyway, I might as well use its threading library for the very nice support it provides for other things such as signal-slot connections across threads.

        • WimLeers a year ago

          QReadWriteLock predates C++11 by many years.

    • fpoling a year ago

      We use QT for real-time data acquisition system. Works surprisingly nice. QT has good event loop abstraction and this is what C++ still lacks.

      • 0xFFC a year ago

        Awesome, I would love to read more about your systems. Do you have blog posts or something?

        • fpoling a year ago

          In Norway it is a common knowledge that QT is a very reasonable choice for soft real-time. So I guess that is a reason people do not blog about it. One doesn't write about obvious things, does one?

  • ptero a year ago

    IMO it is not, but it really depends on what you are a beginner in.

    If you are comfortable with C++ and both traditional and event driven flows, Qt is worth a look -- you may love it or hate it, but you will have something to compare it to and know enough to form your own opinion. Otherwise, pick at least 3 different languages/toolkits and implement a simple application in each to be aware of different ways of doing the same thing. Repeat for a different simple application.

    This vaccinates you against taking a model of your first toolkit and using it as the only way to solve every problem.

    That said, Qt is a solid cross platform toolkit that you can use it to write robust applications. However, it severely locks down your choices. If you use it, force yourself to at least be aware of other options. My 2c.

  • pas a year ago

    It's a hard question, because on one hand nothing beats the next-next-finish install and setup experience of Visual Studio with C# on Windows, but it gets you exactly nowhere. (Okay you can make pretty programs that have a lot of buttons, input boxes, dropdown lists, and so on.) But that's a very good place to be, because then you can start branching out depending on what you find interesting.

    Do you want to make cross-platform things? Sure, try this https://github.com/picoe/Eto (or these http://www.mono-project.com/docs/gui/ )

    Do you want to be closer to the metal? More OpenGL? Go C++ or Rust ( https://github.com/rust-unofficial/awesome-rust#gui and https://github.com/rust-unofficial/awesome-rust#graphics )

    Do you want less setup for your users? Go the Electron way, and/or eventually just build Web Apps!

  • nodelessness a year ago

    I was researching a GUI framework for creating a desktop tool (that is a not very memory or CPU intensive). I felt that Electron was good enough. For the GUI framework it seemed like I can make do with Photonkit[1] and ReactJs.

    [1] http://photonkit.com/

    • yorwba a year ago

      Is your remark about the memory requirements about what the tool's functionality itself would consume, or the complete application (including the Electron runtime)? I was under the impression that each Electron application would require as much memory as an instance of the Chrome browser.

      • nodelessness a year ago

        Yes. I was not building an application like Tableau or IntelliJ. I also was not building anything that had high performance requirements (which electron will definitely fail at) it was a CRUD app - the desktop version of a website with sync functionality.

        The learning curve and full fledgedness of Qt was not needed for me.

  • the_common_man a year ago

    Electron seems to be the preferred approach these days (much disliked by people who appreciate native apps). That said most Qt apps don't look native all the time either (it comes close enough)

    • IshKebab a year ago

      For a beginner (that knows C++) I would think Electron is way more difficult than Qt. With Qt you just: 1. Download the Qt SDK, 2. Start Qt Creator, 3. Open an example, 4. Click Run.

      I wouldn't even begin to know where to start with Electron. There are so many web frameworks and they're all badly documented... whenever I have to make a website I usually start off thinking "Right, I'll do it the 'modern' way this time - with React or Vue... and Typescript.. and and do I need webpack? and...??" but there's so much badly-documented half-finished stuff out there I usually end up giving up and doing plain Javascript. Doesn't help that the modern web stack is a total hacky mess.

      • cpburns2009 a year ago

        This is definitely the state of things. It's funny how people talk as if writing a web application is somehow inherently easier and more efficient than native applications. It's most certainly not the case. You have know at least 3 mediocre languages: HTML, CSS, and JavaScript. And then a separate server-side language if you're not a JavaScript fanboy, most likely a templating language server-side, and maybe even a client-side templating language if you're into that sort of thing.

        I'd gladly take Qt with C++ any day even though I only know enough C++ to shoot myself in the foot with.

        • blattimwind a year ago

          For a long time I thought that C++ was somehow a bad language (because that's the developer-talk-consensus, much like Java), but after I've written a decent amount (something like 100k loc or so as of now) in C++ I reversed my "opinion". C++ allows people to write code that requires intense study to understand (template magic etc.), but writing that code and getting it to work is very hard too, so there is actually very little of that around. Apart from that C++ is a good language which works well for developing applications (and Qt is a very good partner for it). And that's what really matters.

          (Another thing that comes to mind is that there is a huge amount of software for testing, analysing, introspecting and debugging C++ applications - I would say that most other ecosystems are lagging behind in that aspect)

          • workthrowaway27 a year ago

            I think a lot of the broad criticism of C++ is from people who don't use it professionally and have a superficial understanding of it. Professionals usually have specific criticisms of C++ (based on actual problems) which non-professionals interpret as "everyone hates C++". I use C++ professionally and I'm rarely frustrated by it. The language is getting better over time, which is nice too.

            • favorited a year ago

              I have the opposite impression. The people I've seen be the most critical of C++ are C++ compiler engineers.

    • k__ a year ago

      Guess Qt gets more performance?

      But more often than not Electron is good enough and there are even approaches to get JS on the desktop with less memory consumption than Electron.



      • seba_dos1 a year ago

        Why would you even want to use JS on desktop if you have other options available? JS is the choice on the Web, because it's the only choice. It's the choice on Electron, because you can share the code base with Web version or make stuff like editors targeted to JS developers, so they can hack them while using them. But otherwise, it seems like the only worse option you could use for desktop apps is PHP. Why are people doing it to themselves?

        Since we're in a submission about Qt: if you really don't want to touch C++ (which is kinda understandable, although C++ with Qt actually isn't that bad), Qt is very well supported in Python. Using them together is a breeze, and if you really do miss the craziness of JavaScript, you can still use it in QML :P

        And if QML is what you only care about, you can even wrap it with Rust.

        • DiThi a year ago

          JS is a pretty good option in many cases, easier to support in many platforms and arguably easier to develop and debug. What is not, though, is bundling a whole browser. A JS engine is a couple orders of magnitude smaller than a browser.

          • seba_dos1 a year ago

            I've been a professional JS developer for a few years, doing both in-browser and node-based automation stuff (never desktop apps in JS though, thankfully). What I mean is that while new JS revisions are trying to catch up and become somewhat pleasant to write in, there's still tons of baggage of bad decisions from the past that make this language simply awful when compared to basically any other popular language - and those aren't stagnating either.

            Just in order to retain your sanity, you need to use several layers above JS to transpile your code - like JSX when you do UI or TypeScript when you do... well, anything.

            I believe that JS is considered easy only because you can get your first impressive results very quickly when combined with HTML and CSS, which makes it easy to not lose your focus when learning. That might make it a good language to learn in, say, primary school on IT lessons - of course, only if there weren't other, better suited stuff available targeting these cases specifically already. Anything else actually makes JS harder than, say, Python. Or Go. Or C#. Or Java. Or even C++ with Qt (although C++ is easily second worse). Or Rust. There's just so much stuff you have to keep in your head while writing JS, it's not worth it. But you have to let go of "I know it, so I'll use it, no matter how well suited it is" mentality, and that can be challenging.

            • DiThi a year ago

              > Anything else actually makes JS harder than, say, Python.

              It depends on the setup. I use CoffeeScript 2 which gives me most of what I miss from Python (which was my favorite language for years). And when I go back to Python I miss having a debugger as good as Chrome's, as well as some CS2/ES6 features.

              > There's just so much stuff you have to keep in your head while writing JS, it's not worth it.

              Can you give me some examples?

        • seanwilson a year ago

          C++ is packed with undefined behaviour, complexity and cruft. I find JavaScript and extensions like TypeScript much more pleasant to work with.

          • geezerjay a year ago

            > C++ is packed with undefined behaviour

            This alone clearly states that you known nothing abou C++ beyond tired old, meaningless clichés about irrelevant stuff you've heard somewhere and are complaining about something you know nothing about.

            • seanwilson a year ago

              How? Has C++ eliminated undefined behaviour recently? Yes, you can avoid it but it requires years of experience, a significant cognitive load as you work, linting/testing tools and you have to hope all the libraries you're using plus your team members have the same high standard that you're trying to follow yourself. I used C++ for years and knowing there are other languages out there I have no interest in making life hard for myself.

              • geezerjay a year ago

                > How?

                Because you're repeatedly showing profound ignorance on very basic aspects of using a programming language.

                > Has C++ eliminated undefined behaviour recently?

                You are aware that you're parroting on and on about an entirely irrelevant issue, don't you? I mean, any behaviour which has been left undefined in the international standard only means that there is a chance that two implementations may not implement the same obscure aspect exactly alike. And that's perfectly fine because these obscure corner cases shouldn't be used to begin with. That's what undefined behaviour does mean in practice.

                But even if you for some obscure and irrational reason care enough to rely on behaviour left undefined then you also go another standard approach: adopt a specific implementation and check how the behavior was implemented.

                Additionally, rust and go and python and other programming languages are not defined at all and somehow programmers don't get bothered by the fact that these programming languages are entirely undefined. But somehow you feel differently about a language you clearly know nothing about.

                • seanwilson a year ago

                  > But even if you for some obscure and irrational reason care enough to rely on behaviour left undefined then you also go another standard approach: adopt a specific implementation and check how the behavior was implemented.

                  By undefined behaviour, I mean things like null dereferences, buffer overflows, memory leaks etc. that are done by accident and result in serious issues at runtime. I'd rather use a safer language where I can be more productive where possible.

                  Sounds like you're talking about implementation defined behaviour or unspecified behaviour which are different from undefined behaviour (these three terms are defined in the C++ standard document).

                  > But somehow you feel differently about a language you clearly know nothing about.

                  You're not even trying to understand the point you're leaping to attack. You clearly have a chip on your shoulder about something.

              • marshray a year ago

                Here's 1,605 pages of defined behavior. What language are you comparing it to with more completely-defined behavior that can be translated to efficient native binary code for as many different architectures?


          • workthrowaway27 a year ago

            C is for sure. You can avoid most of this in C++ by using the standard library and some of the newer language features.

        • k__ a year ago

          JavaScript has many features that have nothing to do with the language, that make it nice.

          Big community, with many learning resources.

          Nice package managers, with libraries for basically everything.

          Since many people already know JavaScript from working as a web developer, they also have a faster start.

      • DiThi a year ago

        I didn't know about nidium... Thanks!

        Is there any project similar to those two, for Windows?

    • baldfat a year ago

      The anti-Electron people's complaint isn't really the look as much as performance and mostly start up time. To me I sue several electron apps all day and they have held up well.

      RStudio VS Code Discord / Slack (Well slack has not been rock steady)

      • gatmne a year ago

        How's memory usage? I suspect many of us are anti-memory-guzzling rather than anti-Electron.

        • baldfat a year ago

          Well I have 16gb of RAM so it doesn't effect me.

  • thdn a year ago


  • jackmott a year ago

    what does modern mean, and why does it matter, if it is good?

royjacobs a year ago

This is awesome. I can't wait for the KDE binding generator to mature so we can finally start using it more properly from Rust.

inetknght a year ago

Is Qt 5.10 still stuck in the time prior to C++11? Does it have clear pointer ownership and move semantics?

  • gusmd a year ago

    Qt has moved into C++11+ world for quite some time. IIRC 5.7 was an important step in that direction, and they keep moving that way.

    Move semantics are much better. Not sure what you mean by clear pointer ownership, though.

    • inetknght a year ago

      `unique_ptr` and `shared_ptr` semantics

      • gusmd a year ago

        Qt does have QSharedPointer and QWeakPointer. Also, you can use QScopedPointer for things like implementing RAII with custom deleters, etc.

  • jcelerier a year ago

    There is a single rule for pointer ownership in Qt: parents own children. The problem is that it is not enforced by the compiler :p

    • inetknght a year ago

      That rule is not clear ownership. That rule is implied ownership and goes against modern C++ practices.

      If I give something a raw pointer, I don't expect ownership to be taken over by that something.

      ``` auto window_ptr = new QWindow(); auto field_ptr = new QTextEdit(window_ptr); ```

      First, requiring the use of `new` is bad practice in modern C++.

      Second, passing ownership of `field_ptr` to `window_ptr` is unclear. Because I called `new`, I expect that I need to call `delete`.

      ``` delete field_ptr; delete window_ptr; ``` Ooops... now I have a double-free!

      I understand that Qt has been around since long before pointer ownership semantics were defined. But pointer semantics have been around for quite a long time now. The Qt Company really needs to modernize. Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar.

      The raw pointers everywhere and lack of clear ownership is, in my opinion, a barrier to entry. I myself am pretty timid to use Qt because of it and I've got 10+ years of C++ experience.

      • jcelerier a year ago

        > Ooops... now I have a double-free!

        not in this case: when you call delete on field_ptr, it removes itself from the list of children of windows_ptr. The other case would have crashed though.

        But generally you don't even need to have new / delete / make_unique / whatever:

            class MyWidget : public QWidget {
               QFormLayout lay;
               QPushButton button;
               QLineEdit edit;
               MyWidget(QWidget* parent)
                 : QWidget{parent}
                 , lay{this}
                 button.setText("Hello world");
                 lay.addRow("Button", &button);
                 lay.addRow("Some text", &edit);
        these cases will work just fine since everything will be deleted in the correct order.

        Likewise, you can just store a std::vector<std::unique_ptr<QObject>> if it makes you sleep better at night, if the objects are child of the class in, which you're storing them.

        > Even if they don't want to use `std::unique_ptr` or `std::shared_ptr`, they can create their own (hopefully easily compatible) `QInstance` and `QSharedInstance` or something similar.

        There are already various smart pointer types in Qt. But would you really like them to add unique_ptr overloads everywhere ? I'd hate to have to do

            auto my_widg_ptr = std::make_unique<MyWidget>();
            auto my_widg = my_widg_ptr.get();
            connect(whatever, &foo::bar, 
                    [=] { my_widg->do_stuff(); });
        vs today's

            auto my_widg = new MyWidget;
            connect(whatever, &foo::bar, 
                    [=] { my_widg->do_stuff(); });
        • inetknght a year ago

          Learn something new every day. I like this.

          I think my point though is still valid: that it's implicit ownership rules which are not clear ownership rules.

          • gmueckl a year ago

            The relationships are very clear in most code using Qt. When you create a QObject-derived object, one of the constructor parameters is always the parent. Little things like this goes a long way. I never felt the need to express ownership more explicitly with Qt. Whenever I felt the urge to do so, it turned out that I was trying to do something crazy that I probably shouldn't try in the first place...

nikanj a year ago

Qt used to be an absolutely awesome C++ framework. Then Nokia happened, and it turned into a weird Rapid Development Environment™ for Symbian®©.

Does anyone have up-to-date experience with Qt? It's quite clear Symbian is no longer the main target, but did they ever get back to treating C++ as a first-class citizen, or is it still all about QML?

  • IshKebab a year ago

    Still all about QML. QtWidgets (C++) is well maintained but it's clear that they aren't really focusing on it.

    I really wanted to like QML. It gets lots of things right, but it's just so unfinished, and a few things are really weird, like ... I'm pretty sure object IDs sit in a global namespace and can be accessed by any component. A child component can access its parent, which just screams spaghetti.

    And as far as I know there's still no way to have text in a custom widget. I wanted to make a QML graph widget. The lines are easy... but labels. The API for that is still private.

    Another example: I wanted a log window, like a compilation log or something. There's only one QML widget for that and the only operations you can do on it are append(string) and remove(offset, length). You can't remove the first line of text for example. I ended up having to keep a separate array of line lengths, it was a huge hack.

  • majewsky a year ago

    Not sure what you're talking about. Qt 5 didn't remove anything that was there in Qt 4 [1], and added quite a few nice things like native Wayland support and more OpenGL integration.

    Sure, the main development focus is on QML etc., but that's mostly because desktop is a more mature platform than mobile.

    [1] Except for the QtWebkit to QtWebengine transition perhaps. I haven't followed that very closely.

    • nikanj a year ago

      The main development focus is the very thing I was curious about. I remember Qt being slow to support new things eg. high dpi, unless you were using QML.

      Getting the "feel" of a company's priorities can be hard, if you're not actively using their platform. I was hoping someone on HN had a somewhat realistic picture of where Qt is going these days.

      • seba_dos1 a year ago

        Things have definitely accelerated since Nokia regarding desktop platforms. High DPI support has gone through a few iterations and is working pretty well now. Also, Qt is now using open governance model. Qt Quick is still important, but I wouldn't say it's the single, most important thing it used to be anymore.

      • casione a year ago

        It looks to me like they're very underfunded and have completely lost focus. The high DPI "debacle" is a good proof of it.

        • shaan7 a year ago

          Sure /s. We have a Qt app with GUI completely written in Qt. Scales pixel perfect on HiDPI out of the box as long as you make sure to not hardcode pixel values.

    • carlos22 a year ago

      Now the focus of QML is mostly embedded where it really shines. Desktop and mobile is still possible with qml.

    • pjmlp a year ago

      All new APIs are done with focus of improving the QML experience.

      For embedded and mobile deployments, QML is the only option.

      If you try to use a common C++ widget dialog, you will get a tiny desktop like window, regardless of the platform.

      • eql5 a year ago

        Ever heard of

        (to be set before creating the QApplication instance).
        • pjmlp a year ago

          How does it help, when displaying a tiny file selection dialog on an Android device?


          • eql5 a year ago

            These file dialogs are not for mobile! But it's easy to make your own ones, please see: https://gitlab.com/eql/EQL5-Android/blob/master/screenshots/...

            The above is on an android tablet; but it displays perfectly fine on phones, too. Just see the sources of the above project for implementing such a dialog:



            • pjmlp a year ago

              Which proves you failed to understand my point, C++ Widgets don't work everywhere, only QML.

              • eql5 a year ago

                That depends on your screen size! But of course I would never use QWidgets on mobile, with the only exception of direct painting (using a QPainter on a plain QWidget).

                QML is easier anyway, and gets better with every version...

                • pjmlp a year ago

                  Not all Qt developers are happy to be forced to use QML, which again, was my point to start with.

                  C++ Widgets should be able to offer a mobile friendly version of themselves.

                  Which was actually a point that was discussed for the Qt roadmap at Qt World Summit 2017.

                  • eql5 a year ago

                    OK, I understand your point. Good luck, then!

                    • pjmlp a year ago

                      Thanks, but actually I don't use Qt anymore, that bug and a few other ones in 5.4 lead me to use Java and C++/CX for the UI, with common business logic in C++, in a MVVM approach.

                      The approach of re-doing in QML standard UI components is not appealing.

    • jhasse a year ago

      > native Wayland support

      It's still pretty unusable though :/ The default for Qt apps is via Xwayland in Fedora for example.

      • majewsky a year ago

        I'm using some KDE apps under Wayland (Sway, to be precise), and they're definitely not running under Xwayland (as confirmed by `xlsclients`). There is a lot of scaling confusion, but it's far from "unusable". Just not pretty.

        • jhasse a year ago

          Must have been some bug with my configuration then: There were scaling issues resulting in some buttons being unclickable.

    • joezydeco a year ago

      Qt5 dropped the QWindowing Server for embedded platforms.

  • dkersten a year ago

    I'm of a different opinion: that Qt was good, but became great with Nokia. QtQuick (with its hardware-accelerated scene-graph based rendering system for rich UI's with ultra smooth animation) is awesome and QML is a very nice and pleasant way of declaratively creating UI's. Sure, you'd want to minimise the use of javascript, but QML + C++ is a pleasant experience, in my opinion, and much nicer than QWidgets.

    • distances a year ago

      I agree. Plus people tend to forget it was Nokia that relicensed Qt to LGPL, which was a massive gift for most developers. I really liked QML myself when I was using Qt, but even many of those who don't care about QML are likely enjoying the benefits of the more liberal license.

  • ajuc a year ago

    I kinda like QML. I liked qt3 for desktop apps, and pyqt was pretty sweet, but qml frontend and C++ backend is even better.

  • user5994461 a year ago

    I've been on Qt projects, it's all C++.

    Never seen any QML, don't know why people think Qt is about QML and javascript.

  • digi_owl a year ago

    My impression was that QML was already happening before Nokia got involved.

    • seba_dos1 a year ago

      QML was heavily inspired by EFL's Edje and the QEdje project, which was started in the middle of 2008. Qt Kinetic was initially presented at the end of 2008, however, it was still pretty much widget-oriented (the closest you could get to QML's was to use QGraphicsWidget by yourself, like Plasma 1 did). Qt Declarative (later called Qt Quick), including QML, has been shown in May 2009, a year after the acquisition by Nokia (June 2008, announced in January).

billfruit a year ago

Haven't used QT in a long time.Have they done away the with ’moc' and code generation? I found it extremely annoying that while we were using QT we weren't actually using c++, but a strange, language that looked like c++, but was actually further processed by qt to generate the c++ code. Are they done with that shebang?

  • ahartmetz a year ago

    The C++ that you write does not run through moc. It uses a few special macros, each of which either inserts something trivial (e.g. a virtual method declaration for Q_OBJECT) or nothing at all (e.g. "emit"). In another build step, moc scans for those macros and generates additional code accordingly. The features added by that generated code are super useful and are implemented in separate methods, i.e. code that does not somehow appear in the middle of your own.

  • manyoso a year ago

    Every C++ toolkit out there does something similar. Look at Herb Sutter's talk on metaclasses and see he says the same thing.

  • iKlsR a year ago

    Without moc their is no signal slots and the handy stuff you get from plopping Q_OBJECT in your derived classes. So it's not going anywhere.

    • billfruit a year ago

      Can't they figure out a way to do that in pure c++ yet? In other words why does C++ lack reflection, and only seems to have a half baked RTTI? Perhaps the QT guys and other c++ application programmers didn't lobby C++ standards committee strongly enough for that?

      • dkersten a year ago

        Sure, but there's 1) a performance hit because things that can be done at compile-time currently, have to be done at runtime, and 2) syntactically verbose/cumbersome. They've decided that these things are not worth it to most people.

        Besides, it still is C++: you can totally compile everything without the moc (although its probably not very useful to do so), since the extra keywords are just #defines.

        I've personally never had any issues with the moc (but I did only ever use QtCreator/qmake, so...)

      • user5994461 a year ago

        There can't be reflection. C++ is compiled into machine code, it's a one way process.

  • symlinkk a year ago


    • workthrowaway27 a year ago

      Not sure why you're being downvoted, since your answer is correct.

DonHopkins a year ago

What JavaScript engine is Qt 5.10 using, and have there been any recent changes to that engine, or the way it's integrated with Qt?

billfruit a year ago

Annoying thing with QT, the official pronunciation sounds like ’cute’, and some interviewers insist on calling it that.

  • baldfat a year ago

    Officially / Corporately: Cute


    I have never heard any company ever call it Q.T.

    Community: Q.T and I rarely hear it called cute. I usually call it Q.T. even though I know it is cute.

  • j1elo a year ago

    I recently attended a talk by one of the Qt developers, and he briefly mentioned that 'cute' is not an intentional cute name, instead it just comes from the way the letters in 'Qt' are said in norwegian language. As simple as that.

    Him not being norwegian, I cannot know if that is correct or just something that is said in their office in Oslo...

  • marsRoverDev a year ago

    I know a former Qt dev who pronounced it 'cute', so I think it's a bit of a Gif vs Gif type situation.

  • shaan7 a year ago

    QT = QuickTime :P

liquidnitro02 a year ago

Awesome cant wait to check out the new features!

happy_rust44 a year ago

The features of the C language were added with purpose. They were intended to solve a real problem and solve that problem they did. Simple arithmetic with promotion. Automatic register allocation with a portable (between compilers) ABI. A simple-but-handy preprocessor. And so on. C is also a lean language: a single person can feasibly write a C compiler in a relatively short time (tinycc is a C99-compliant C compiler written in just 65kLOC of C!). C set out to achieve a clear goal and it achieved its goal. Thanks to the cleanness of C lots of quality compilers came on the market quickly and even decent OSS solutions were available early on.

In contrast, C++ never had a clear goal. The features of C++ were added almost at random. Stroustrup's original idea was essentially "C is cool and OOP is cool so let's bolt OOP onto C". Retrospectively, OOP was massively overhyped and is the wrong tool for the job for most of the people most of the time. Half of the GoF design patterns just emulate idioms from functional programming. Real OOP languages like Smalltalk and IO express many useful things that C++ cannot. The feature that C needed most was perhaps parametric polymorphism (aka generics in Java and C#, first seen in ML in the late 1970s) but instead of that C++ got templates that weren't designed to solve any particular problem but rather to kind of solve several completely unrelated problems (e.g. generics and metaprogramming). Someone actually discovered by accident that C++ templates are Turing complete and they wrote and published a program that computed prime numbers at compile time. Wow. A remarkable observation that led to decades of template abuse where people used templates to solve problems much better solved by other pre-existing solutions such Lisp macros and ML polymorphism. Worse, this abuse led to even more language features being piled on top, like template partial specialization.

The massive incidental complexity in C++ made it almost impossible to write a working compiler. For example, it remains extremely difficult to write a parser for the C++ language. The syntax also has horrible aspects like List<Set<int>> being interpreted as logical shift right. None of the original C++ compilers were reliable. During my PhD in 2000-2004 I was still stumbling upon dozens of bugs in C++ compilers from GNU, Intel and SGI. Only after two decades did we start to see solid C++ compilers (by which time C++ was in decline in industry due to Java and C#).

C++ is said to be fast but the reality is that C++ is essentially only fast when you write C-like code and even then it is only fast for certain kinds of programs. Due to the "you don't pay for what you don't use" attitude, C++ is generally inefficient. RAII injects lots of unnecessary function calls at the end of scope, sometimes even expensive virtual calls. These calls often require data that would otherwise be dead so the data are kept alive, increasing register pressure and spilling and decreasing performance. The C++ exception mechanism is very inefficient (~6x slower than OCaml) because it unwinds the stack frame by frame calling destructors rather than long jumping. Allocation with new and delete is slow compared to a modern garbage collector so people are encouraged to use STL collections but these pre-allocate huge blocks of memory in comparison so you've lost the memory-efficiency of C and then you are advised to write your own STL allocator which is no better than using C in the first place. One of the main long-standing advantages of C over modern languages is the unpredictable latency incurred by garbage collectors. C++ offers the worst of both worlds by not having a garbage collector (making it impossible to leverage useful concepts like purely functional data structures properly) but it encourages all destructors to avalanche so you get unbounded pause times (worse than any production GC). Although templates are abused for metaprogramming they are very poor at it and C++ has no real support for metaprogramming. For example, you cannot write an efficient portable regular expression library in C++ because there is no way to do run-time code generation and compilation as you can in Java, C# and languages dating back to Lisp (1960). So while Java and C# have had regular expressions in their standard libraries for well over 10 years, C++ only just got them and they are slow.

C++ is so complicated that even world experts make rookie mistakes with it. Herb Sutter works for Microsoft and sits on the C++ standards committee where he influences the future of C++. In a lecture he gave his favorite 10-line C++ program, a thread-safe object cache. Someone pointed out that it leaks memory (Herb Sutter's favorite C++ 10-liner has a memory management bug).

My personal feeling is that the new Rust programming language is what C++ should have been. It has useful known features like generics, discriminated unions and pattern matching and useful new features like memory safety without garbage collection.