I've been tasked as a Qt dev at my day job for the past ~2.5 years writing cross-platform applications. It works, the documentation is pretty fantastic, and you'll find no shortage of help online to get over the admittedly decent learning curve if this is your first swing at "c++" programming.
Edit: As mentioned below, PyQt is also pretty fantastic. My most recent venture into the PyQt world at work was writing a touchscreen application on a 800x450 touchscreen, and it all "just worked."
- QT is a great and very-well designed library with solid performance, a fast release cycle and superb documentation.
- It provides a rich and well thought-out component library.
- It is used by many companies to build real-world applications.
- It has a pretty liberal licensing scheme. The commercial license (if you need it) is not that expensive.
- It provides bindings for many scripting languages like Python.
- It has great IDE support and lots of tooling around the core library that make GUI design easier.
- It emabraces model-driven design and has stylable components (via CSS).
- It will usually beat most JS / WebKit based frameworks by a large margin performance-wise and makes distribution of your application much easier (forget about >100 MB downloads).
I consider it very expensive. More than +US 3000/year for 1 developer?
The open-source is useless for desktop apps?.
Andy Brice (Oryx Digital, UK) has been developing his successful desktop software product, Perfect Table Plan (a seating planner software for events), in C++ and Qt, and selling it for over 10 years. (His newer product HyperPlan may be done in that stack too.) I've been a reader of his blog from some time: successfulsoftware.net. Many good tech and more biz tips there (for the software product biz - for desktop apps). And his app is cross-platform between at least two of the big 3 consumer OS's, IIRC (or maybe all 3) - Windows, Linux and MacOS.
Edit: I had also checked out Qt (v3 or 4) and tried some of the example apps (reading, compiling and running them) and also bought and read most of a book on Qt programming by some well-known Qt developers (don't remember the book or author names right now, but they may have included some of the original Qt creators). The impression I came away with was similar to that of some of the other commenters here - Qt seemed to be a well-designed library, not too difficult to learn, and with fairly good documentation at the time. I could understand the signals and slots mechanism it uses, without much trouble. Didn't get the moc part though (was not a C++ expert, also did not look much into moc) but it may not be needed to know that well, may be enough just to be able to use it.
FWIW I never had to delve into understanding what exactly it does apart from "is invoked by build system to generate some code" in the course of many years of working with Qt.
I've got a pretty vanilla workflow with CMake, the GNU tools, the STL and emacs/KDevelop/CLI to tie it together. It works across all platforms and all problem domains. But the internet is telling me that if I want to make native GUIs I have to be in the parallel universe of Qt with its own version of CMake, some magic custom build steps, its own IDE and some XML stuff that you really really should use otherwise things will get messy.
Is this just b/c Qt is old? Is there a bigger reason for the Qt-verse I'm just not seeing? And is this all a lot less of a headache than I'm imagining?
PS: Are there any clean frameworks that are tied to modern C++?
I've included some answers below:
* One can use Qt with CMake and for a large project probably should, because qmake can be quite limited.
* Qt Creator is not a must, but it's a good C++ IDE and was designed to work well with Qt. I think KDevelop should have pretty good Qt support too.
* The only XML I can think of are the UI designer files. If you prefer you can write the UI code by hand, but it's quite barbaric IMO :) Those files are just parsed and transformed into a ui_foo.h file which contains an inline setupUi method that one should call from their widget's constructor.
* The custom build step is running the meta-object compiler. It's necessary for signals and slots (Qt's ubiquitous subject-observer implementation) and for e.g. reflection if used. This is only really needed for classes that inherit from QObject, such as all the UI classes.
If you want to be really hard-core, you can build the entire UI in code, without inheriting from the UI classes, and then I think this extra build step is not needed, but you will lose covenience and some customization possibilities. They've also added signal-to-lambda connections, so one is not obliged to use slots at all AFAIK.
All in all it's not bad at all. If one wants to have a cleanly separate Qt and pure C++ code-base it's possible with some glue code.
It really isn't much of a headache.
Or you can create components in C++ callable from Qml, but this requires some extra code ( and work ).
Isn't Python just as slow as Electron?
A few 100MB of RAM or disk space extra is a nonexistent issue as well to typical users. I know some developers get very offended at a program using a bit more RAM or CPU than it should be but developer efficiency is more important most of the time so it's a completely rational trade-off. Some of these apps wouldn't exist at all if everyone insisted on native everywhere.
It's all just my opinion as well, but approaches like Electron are very efficient at creating good cross platform apps. Developing and maintaining several native apps is a huge resource drain when most users aren't going to care.
In fact, every time you hear a non-programmer complain about their computer it's usually not a hardware, but a software like electron that's ruining their experience.
OSes have started to add application profiling recently, so once every mainstream OS starts loudly pointing a finger at offensive applications (like "uninstall Spotify/Slack and you'll get 4 more hours of battery life"), you'll start hearing complaints from non-programmers.
Actually, Task Manager showed 90% of my 8Gb ram being utilized and caching to disk constantly with most of the ram and CPU being hogged by eight(!) Slack threads. This is with Slack minimized and sitting idle.
The fix was to replace the Slack/Electron app and use the browser version instead. That solved it.
Electron is a super cool piece of tech that could enable all kinds of great app development but needs to go on a serious diet first.
I can get literally double the battery life on my Thinkpad if I close Slack, Messenger for Desktop, Atom/VSCode. Chrome uses multiple extra watts of juice in powertop than Firefox, and every Electron.JS application is really just a Chrome instance.
Slack uses 400-500MB of memory. That's 15% of my RAM. For a chat application. Every Electron app is in this range. None share a runtime or memory footprint.
Believe it or not, not everyone has 16GB of RAM. This level of inefficiency is utterly inexcusable.
Code Helper is from VSCode. VSCode, Evernote and Slack are all completely idle right now. I don't think they should be using any memory at all. Especially not over 700 MB. I don't even understand how they could possibly be using that much memory.
Is it just memory leaks?
Fact is if the ram it available, an app should cache as much as possible. It has no idea what you'll need next, so better it use a free resource to reduce latency.
You cannot think of an app in just terms of the text it handles but also window pixmap data.
There's a problem, though: it doesn't work that way.
The size reported by Windows is (if I'm not mistaken) the committed heap size of the program. Unless the application actively surrenders allocated pages back to the OS (and hint: no application does that), that memory is committed.
Edit: to add some color: when a program calls malloc, memory is allocated from pools inside the process itself. If no memory is available in the internal pool the allocator will call out to the OS for additional pages (in the Unix world this is a call to sbrk). When free is called, memory is returned to the internal pool but is not surrendered back to the OS and thus remains committed to the process. Actually reducing the committed heap size once again requires an explicit call to the OS (e.g sbrk).
Of course it may be swapped out by the OS, but that just means slow disk I/O when that application comes to the foreground or accesses those swapped pages (which presumably contains the precious cached data you refer to).
Should the OS use memory to cache transient data? Certainly. OSes typically contain logic to throw away those caches if memory is needed.
But applications that do this without intelligently surrendering cached pages back to the OS when memory is low (as an OS does with its own caches) just put that much more memory pressure on the overall system itself. And I've never heard of an application that does this. Certainly I've seen no evidence that Electron is that sophisticated in its memory management, though I'm happy to be proven wrong.
Anecdotally: I am currently running VSCode and Task Manager reports 19,8 MB of memory usage right now (vscode Window being idle, with 6 files opened on Win10)
If you "Ask HN" for opinions how can you take those opinions with a grain of salt?
Surely if you can't trust HN commenters then Ask HN is a waste of time.
Spotify is also a bit slow and clunky, but it's not too bad. There's no reason why they couldn't aggressively pre-fetch a lot of pages to make the UI feel snappy. E.g. "Browse", "Radio", and all the tabs under "Your Music". And if you're playing a track, just pre-fetch the artist and album pages. If I can click something in the UI, it should already be loaded.
But even when stuff is already cached, the UI takes about 500ms to render the new page. Sometimes it's only a few hundred ms, but there's a nasty black flash before it renders. the new page. There's really no reason for that either. There are so many ways you could speed that up to make it instant. For example, just render everything above the fold, then add the rest of the content later.
Spotify's internet connection detection drives me crazy sometimes. Sometimes it takes 20-30 seconds to get back online, but I don't think that's related to JS. Their polling interval is just too long. There's no reason why they couldn't poll once per second and come back online immediately.
I can't help but be reminded of the "VS Code uses 13% CPU when idle due to blinking cursor rendering" post that was on HN earlier last week, referring to the following issue:
Well there isn't exactly a choice of what spotify client to compare it to is there - so users have to use it by default rather than be 'happy' about it.
Why isn't it more popular? Because it's written in FreePascal: a modern, object-oriented version of Pascal. A lot of readers will stop right here and never this give project another glance, the thought of using Pascal as simply too outdated or embarrassing.
If you do give it a try, you'll discover one of the best and most overlooked options for native desktop app development. Any downsides? A major one in my view: poor and patchy documentation (which will be a barrier and block for many).
I did this a few months ago:
Digital Clock created in FreePascal / Lazarus:
This is suicide.
Is it lack of mindshare, lack of "hotness", some specific deficiency, or... ?
> Why isn't it more popular? Because it's written in FreePascal: a modern, object-oriented version of Pascal. A lot of readers will stop right here and never this give project another glance, the thought of using Pascal as simply too outdated or embarrassing.
Personally, I've never heard of the framework and FreePascal would definitely be a reason not to adopt it for me, as I'm not familiar with how to fix problems should they arise, while I would be able to troubleshoot an app written on Java or better yet NodeJS.
I've seen apps that run with a double-click, stay open, and open my browser tab on 127.0.0.1:43110, with the entire app right there. It takes very little to develop, and it's lightweight because it's already using a runtime we all use most of the time (a web browser).
For the development side, this is pretty much the same experience as developing for Electron, but without the RAM/battery drainage.
I mean the user base and the scope is kind-of limited, but it's really easy to build thin-clients and some certain types of applications in Elisp. And against all prejudice, modern Elisp is quite a pleasurable language to write in. Furthermore, it's a joy to use that sort of "apps" in emacs and the community really likes it when those pop up. Also, there already are rather featureful apps like Gnus, Magit, EMMS and Elfeed, and the user is allowed vast customisation even without you really thinking about allowing it (advices, monkey-patching, keybindings, hooks, etc.).
P.S.: While I don't suggest this as seriously as those who suggest Qt and WxWidgets et al., if your demographic is hackers, you can consider it.
Don't you find the lack of 3rd party library support somewhat difficult ?
We get excellent third party support for oxml, secure blackbox, gnostice components, devexpress components, uniqui and many, many other libraries.
So I had to put it in virtualbox in windows xp. Great nostalgic experience I must say. Back when I truly enjoyed programming just for the sake of trying something new.
Ha ha, I still have an old CD of Delphi 1 somewhere.
* If some of the code is likely to be reused with an associated website I would go for Electron. Using ReactJS.
* If an associated mobile app is also possible, I would take a look at React-Native, which have some embryonic desktop technology counterparts. This option can be combined with a webview.
* Worth also looking at Xamarin, especially if there's existing investment and skills in .NET (e.g. existing Windows app being migrated).
I use Electron apps daily: Atom, Spotify, and Wmail, and I'm perfectly productive with them.
Atom is definitely slower than Sublime Text, but I'm not sure it's Electron's fault (I read that it isn't). As for Spotify and Wmail, you can't even tell it's Electron, and certainly no average user cares or would ever know.
I would do what makes sense for your app and makes it easier to port it. Electron works great for that, and you can use the same code to offer a web app.
The Web is a race to the bottom in the quest for eyeballs. If eyeballs aren't what you desire, you can give the set of users you do have a much better experience: smoother interactions, better adaptation to system preferences, automated security and functionality updates to components via the OS distribution, better accessibility, etc.
If you and OP want to disagree with the premise that used software is good software, and go in the opposite direction, that's fine - that's the point where we agree to disagree and go home.
What about rdio? Back in the day, I remember noticing they had a much better music archive than Spotify in some areas like prog. Still, I never made the switch. (The way they organized music was terrible.) Apparently, neither did anyone else.
I could go on. All these Spotify competitors, all with decent libraries. How did Spotify end up winning?
I'm not saying that songs are unimportant, but if you have trash ux people are going to find an alternative.
(edit: I'm an amateur musician, I do know quite a bit about the online music sphere, and I've been a paid user of both Deezer and Spotify in the past. You usually don't know who you're talking to on the internet, so better don't assume things.)
Anyways, what I'm saying is that using electron is not really correlated to "bad app" and not using electron is not correlated to "good app".
I used to find my music elsewhere and could do it again if I had to.
I've had the spotify app crash my computer a few times. And then there was that fiasco a while back about it writing many, many gigs of data to SSDs and shortening their lifespan. Convenience will always trump software quality, but as soon as there is a competitor with better working software at a decent price, I'm jumping ship.
That having been said, I don't use Spotify a lot, as the UI is really cumbersome and puts me off the entire thing.
Also I use then through a scripting language https://github.com/mingodad/squilu OS X, Linux, Windows, (iOS && Android through browser/native) ...
For other Windows/Mac stuff I'm working on, I use C++ for the cross-platform code, and Win32 API / Obj-C for the platform-specific interface layers.
Also: No moc compiler and you can statically link it without paying for a commercial license.
Then there's [Kivy](https://kivy.org/#home). Love that.
The fact that the dotnet core app does the heavy lifting makes the whole application relatively fast.
See an example here https://www.ccasystem.io/Resources/DownloadDesktop
I would personally lean towards doing the last, with the target being the JVM -- that doesn't have to mean use Java, as there are many much better languages that target the JVM.
As a dev, Unity is nice, but brutal on batteries for normal apps. I wonder if there's a way to hack it to only run the various loops on event changes and thereby be more efficient...
Here's hoping some Microsoft people are reading this
Compiling compression library...
Compiling Red console...
--== Red 0.6.2 ==--
Type HELP for starting information.
>> view [text "Hello World"]
*** Script Error: view has no value
*** Where: catch
I'd choose C