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.
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:
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.
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.
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.
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.
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.
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.
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. :/
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.
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?
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.
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.
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).
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.
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.
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.
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.
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. :)
I mention bits and pieces on my app's blog [0]. But more interesting to you may be a Wiki I created on GitHub with the things I had to learn about PyQt the hard way [1].
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.
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.
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.
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.
Thank you for having gotten a license. I've given it a lot of thought and don't think there is a way to open source and become financially viable. See for instance https://fman.io/blog/why-fman-isnt-open-source/.
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.
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?
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.
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.
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...
> 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.
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]
> 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?)
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.
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.
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.
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.
> 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
... 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.
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.
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.
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.
GPL:
Regardless of linkage, your code must be under a GPL compatible library.
The GPL considers the software as a single work regardless of linkage.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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)
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.
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.
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)
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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?
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)
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.
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:
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();
parent_layout->addWidget(std::move(my_widg_ptr));
connect(whatever, &foo::bar,
[=] { my_widg->do_stuff(); });
vs today's
auto my_widg = new MyWidget;
parent_layout->addWidget(my_widg);
connect(whatever, &foo::bar,
[=] { my_widg->do_stuff(); });
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...
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?
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.
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.
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.
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.
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.
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:
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...
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.
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.
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.
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.
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).
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?
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.
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?
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...)
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...
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.
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).
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!