Ask HN: Should Qt be considered in the place of electron?
When a cross platform app is required, Electron is often mentioned first: Should Qt be considered to fill that gap (As in the new QML-y Qt)
The only Qt app I've used recently is VirtualBox, which is terrible on the Mac. The controls don't look or work right at all. On Windows, it's less bad, but still noticeably non-native.
I searched the web and found that Google Earth Pro also uses Qt, so I downloaded that. It looks awful, too. The scrollbars, split panes, buttons, and toolbars look wrong. Checkboxes are drawn mangled, animation is absent, and the outline view doesn't size its rows correctly so the bottom half of text is cut off. Despite language being "System default" in the Earth prefs, and English being the top language in my System Prefs, part of the UI is in Japanese (my #2). The view right after launch: https://i.imgur.com/eDvSoUm.png
I think a good first step would be looking at existing Qt apps. Are you OK with the quality of apps like VirtualBox and Earth? Alternatively, do you think you can do a better job at this than Google and Oracle?
I think if you're planning to write a typical Qt app, in order to make 'native app' fans happy, you're going to be in for a surprise.
On Windows and Linux (primarily Ubuntu), KeePassXC, VirtualBox and VLC have been pretty good in my experience and they're Qt as far as I know. Dropbox uses Qt as well, however, it's interface is minimal. Electron doesn't even try to look or behave natively for what it's worth.
VLC's Wiki [1] says: "Qt / Qt4 is the default, plain, graphical, interface to VLC, made using the Qt library (Linux users may need to have this installed). It is used as the default interface on the Windows and Linux versions of VLC media player from version 0.9.0 and above."
[1]: https://wiki.videolan.org/Qt_Interface/
I googled for "dropbox mac qt" and only found this page [2] from 2014 which says they were experimenting with rewriting the Dropbox UI in Qt for Linux and Windows. The linked post [3] says the Qt rewrite is for Windows and Linux only.
[2]: http://www.webupd8.org/2014/07/dropbox-ui-rewritten-in-qt-fo... [3]: https://web.archive.org/web/20141015093406/https://forums.dr...
I consider Qt (along with Gtk+) to be native on Linux -- there's no more-native toolkit that it's wrapping or emulating.
So I find it interesting that these cross-platform applications (Wikipedia lists 9 platforms for VLC!) both use Qt for only 2 platforms, and 1 of those is where it's native, anyway. These are mature applications which have clearly put a lot of effort into both user experience and cross platform support, and they have already gone to the trouble of implementing their UI in Qt, but for most platforms they choose not to use it.
What I get from this is: Qt is useful as a cross-platform GUI toolkit only for targeting Windows. Is that overly cynical?
And how native do the controls on electron apps look? IME these apps always look completely alien and won't use the native controls with the native theme. I see this criticism frequently and it seems like people hold Qt to a higher standard than electron and then dismiss it because it doesn't meet that higher standard.
Completely custom -- but at least they're not chopping off the bottom 2/3 of a line of text.
I hate Electron as much as anyone, but I really don't understand how being able to read all the text in a user interface could be considered an unreasonably high standard for a software program.
Of the examples I've seen posted, half have exactly the same weird UI bugs, and the other half turned out to not be Qt at all.
I'll grant that it is possible that Qt is perfectly fine at cross-platform GUIs on all of its supported platforms, and all these poor examples can be explained by (a) these particular developers simply did a poor job, (b) they all failed in the same way (maybe there's a flag to make all Qt controls look and act non-native, which they set by accident?), and coincidentally also (c) everyone writing good cross-platform apps happens to limit their use of Qt to just Windows and Linux, for completely unrelated reasons. I'm of course skeptical, but I grant this is all possible.
Even if so, I maintain that it's still an unnecessary engineering risk to use a tool for a task where you've never before seen it used well and successfully.
Besides, I disagree that bugs like drawing checkboxes wrong (until you resize the window) are "likely an application specific bug". I've never seen any other GUI toolkit mess up drawing checkboxes. That's just fundamental. I don't even know how I could screw that up using any other toolkit.
I'm happy Qt/Mac exists, it made our Mac port commercially viable, and a couple days of polishing work would make the UI "good enough". If we'd done continuous deployment it would have been annoying.
Not sure what this "appeal to authority" is supposed to mean. I've seen -- and worked on -- many high-quality Qt applications. Granted, I'm not a Mac user, but on Windows and Linux they can look just as good as any other "native" applications.
"I think a good first step would be looking at existing Electron apps. Are you OK with the quality of apps like the Slack client and Microsoft Teams? Alternatively, do you think you can do a better job at this than Slack and Microsoft?"
Another GUI-framework I've enjoyed using is wxWidgets, which provides a thin abstraction to a platform's native widgets. Has a bunch of language bindings, and a pretty liberal license as well.
Accessibility is only achieved by the creator's intention.
Accessibility is only achieved by the creator's intention.[0]: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...
I think wxWidgets supports a variety of bindings for different languages as well.
Never used it but C#/netcore might be a good choice as well. I've only used C# with winforms though, so the danger I'm talking out my ass is high.
I hate working with web frameworks but the network effect is real and not in favor of Qt. Perhaps there was a time when Qt was thriving and innovating, but right now it seems like it's just a bunch of fortune 500 companies paying 1-2 Qt developers to maintain legacy software.
Sometimes I wonder if there is an alternate universe where Qt won "the battle" and made the world a better place. Sadly for us, that didn't happen here.
Yeah, I don't know how much experience you have with Qt but widgets are far from being "finished". There's plenty of things that could be improved if their focus wasn't on Qt Quick.
The use of Qt Widgets is declining (albeit slowly), as stated in http://blog.qt.io/blog/2019/01/14/qt-customer-survey-2018/. You're telling me that they're going to support two different technologies that do the same thing without giving preference to the newer, technically superior one?
Qt Quick is intended to replace Qt Widgets, but it isn't currently at a stage where that's feasible -- hence my apprehension.
From the first post, I assumed the commenter meant something like, "in Qt 6 QWidgets will stop working", which is insane.
The first one was in 2013, so Electron was not an option at the time, I needed a runtime to run my webapp (in the healthcare industry, for many legal reasons and budget, I could not and would not have it hosted on the internet, so I needed it to be a desktop app). At the time it was webkit, and it already was a great experience. The app was part C++, part Angular1, all the data was stored locally in a sqlite db. The company is still running, and the app is on the verge of being rewritten (basically because the new CTO is not much into C++) with Electron.
Second project, started in 2016, originally a React Native app (IOS and android), but many customers wanted a desktop/web version. Web was a lot of work because the app depends on storing data locally (sqlite again), so to make it fast, I did a first prototype with Electron, spent a week on but I had many issues with building native nodejs modules, so I dropped it and back again on Qt, but today it's all chromium-based instead of webkit. So I wrote the native part I needed in C++ (was fast and easy because the Qt library covers a lot), bridged it to the application, and the port of the ReactNative app was completed in less than 2 months.
I like Electron very much, but if you know C++, Qt is great competitor as a webengine runtime. Of course, I had my share of issues with Qt, but I don't feel like it would have been really better with Electron, whatever the framework, there are always issues.
A third option if you're too afraid of C++ or one of the Qt bindings, and you really need something web-like, is JavaFX.
It's hard to beat the edit-test-debug cycle of Electron, where I can tweak a line of code, hit Cmd-R, and see the results in less than a second.
Never used it myself but I wonder if it is a more performant alternative to Electron
There's your answer.
I now fear this might become viable and websites will become a black box where things like ad blockers don't work.