I hear this a lot, as a contrast to Electron, but I haven't seen any examples of good cross-platform Qt apps.
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.
> 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.
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.
Curious. VLC on MacOS doesn't exhibit any of the weird UI glitches that other Qt apps have, and an inspection of the package shows it doesn't contain any Qt frameworks.
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."
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.
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?
> The controls don't look or work right at all. On Windows, it's less bad, but still noticeably non-native.
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.
> And how native do the controls on electron apps look?
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.
A single and likely application specific bug doesn't demonstrate much. Having the wrong language for that entry is likely a google earth problem, not a qt one, the text cutoff could be a number of things, like the developers manually setting max height, in which case you'd see similar results of the did the same in electron/css, gtk or just about anything else.
Technically true -- which is why my original question was: is there any example of a good cross-platform Qt app?
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.
> Alternatively, do you think you can do a better job at this than Google and Oracle?
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?"
I shipped a commercial app on Qt in the early 00s. The Mac port just never nailed the finer UI details to the same standard as Qt/Windows and Qt/Linux. Qt's customers ended up being the embedded market and phone vendors, I don't think their Mac port was ever adequately resourced.
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.
Electron apps look and act oddly, in a different way, and no, I don't have any installed. I only have one Qt app (VirtualBox) installed, because it's the only free virtualization system I know of. I only use it via Vagrant, so I never have to see it.
Heck yes.
I still don't get how so many creators of apps justify choosing Electron to themselves, what with all the downsides (resource usage, power consumption, accessibility, security, and so on).
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.
I've used an editor and two IDE's that are built off wxWidgets. They are all fast and responsive. And support Windows, Mac and Linux. As in they 'work' for all three.
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.
Well, it brings the usual web security issues to the desktop, dragging with it much of the browsers' attack surface.
Also, there's been a bunch of CVE – there's one [0] in particular that springs to mind.
Accessibility is only achieved by the creator's intention.
That's a problem. Native widgets come with accessibility built in (to the extent accessibility is supported on the platform in question).
As much as I enjoy working with Qt, I wouldn't bet on it for the future. QML support still seems a bit iffy and being told QWidgets are being phased out is disheartening. The framework is in a sort of limbo stage where newcomers don't really know how to proceed. The lack of popularity (outside of some niches) doesn't help either.
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.
I believe "old school" Qt has a number of professional niches that wouldn't dream of using anything else. Certainly visual effects software is Qt heavy.
No, they are just mostly finished and aren't seeing a lot of new feature work being done ,if any. Qml is a way better way so that's what they are working on. It gets better every release, and that guy doesn't have a clue. Sorry. Just for the record, QML is awesome.
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.
Yeah, that's not true. They have said that Qt4 widgets are feature finished, and not being deprecated. Obviously eventually there will be little use of the older way, but they have repeatedly said they are not deprecating them. Believe what you want.
I'm aware that they aren't being deprecated, but that doesn't mean they aren't being phased out. When I say it is being "phased-out" I'm referring to how it will no longer be advertised as the optimal solution to a problem. Perhaps we're just arguing semantics at this point?
That is so not true. Like, nothing you said is true.You literally have zero idea of what you are saying.The reason not to use Qt for cross platform work is you don't know what your doing. Pretty much it.
Most of my points above are personal opinions, so I don't know how I could be spreading misinformation. I'm describing things through my own perspective and I may or may not be categorically correct.
Maybe Qt is full of potential in your country? Perhaps Qt is booming in your industry? I haven't had those experiences. If my sentiments are misplaced, just inform me with reasonable arguments and I'll gladly change my view. Telling me that I'm just wrong doesn't help anyone.
Helps you stop misinforming people, which helps everybody. There is no "in your country", just stop. I don't have time to be your personal instructor, and I don't want to argue with you. Educate yourself before giving your opinions that might be read by people seeking help.
So do you have any intention of trying to explain why that commenter is wrong, or are you just going to keep condescending them about being wrong without any substantiation? You haven't refuted a single claim made in this thread with a source, an example, documentation or even your own anecdotal experience.
Takes none of those things to say the truth. I stated a fact, not that I was making a case. You are not the judge. So what your saying is I have to prove what I said was true, but he can say what he wants without challenge ? Really ?
Actually, this is funny because that's literally what I have been doing for the last 2 startups I co-founded.
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.
Does anyone else find Qt difficult to setup/compile and find the qtmoc hoops that are necessary really frustrating when it comes to compiling projects in a non standard way?
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.
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?"
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.
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.
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.
Accessibility is only achieved by the creator's intention.
[0]: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...
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.
Maybe Qt is full of potential in your country? Perhaps Qt is booming in your industry? I haven't had those experiences. If my sentiments are misplaced, just inform me with reasonable arguments and I'll gladly change my view. Telling me that I'm just wrong doesn't help anyone.
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
https://github.com/status-im/react-native-desktop
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.