Qt Quick WebGL Streaming
blog.qt.io
blog.qt.io
A while ago I entered a hackathon visualization challenge using Qt painter for rendering. I expected C++ and Qt would slow me down but the rendering speed and expansive drawing primitives were valuable! They greatly reduced my iteration time and increased fun.
Today I never create new frontend projects with Qt. I may use Qt creator with cmake for backend components, but the frontend is HTML and JavaScript with libraries like React, Three.js, D3, and bootstrap. The experience is still cross platform, but also one step away from launching as an internal portal. Distribution this way is much easier, but the tools are so flexible you need more diligence to keep the code maintainable over larger teams.
I struggle to see where you would prefer Qt for frontend code if you don't need a native app.
We're becoming more rare these days (especially in the eyes of the Qt developers), but we still exist.
With that said, I got into a debate a while back on HN that web technology is more expressive and miles ahead of desktop frameworks and I got buried for it. What would be nice is if someone ported ReactNative to compile to QT.
How about actual native UIs instead of ugly, non-intuitive, slow and massive Electron apps?
I say this being a dev who works with both Qt and Electron on a daily basis. Electron has its place - but its place isn't good desktop and mobile apps. Qt is much better suited there.
Electron is only well suited if your team is extremely familiar with web dev but nothing else and you have no ability to hire a good desktop team or you need to interact with a web-only frontend library.
Just about everything in Qt is preferable - native look and feel, proper layouts, high performance rendering, small distribution size. I struggle to think of any way in which Electron is better except for perhaps library support these days.
Yeah, and it's called Hacker News - beyond that no one really cares, and uses Qt.
This might sound like a troll, but the bubble effect on HN really is that strong. The community sometimes has a strong tunnel vision and doesn't realize how it's constrained by what's on the HN front page.
Electron (sadly imo) is being used in plenty of newly developed cross platform applications, a lot having users that have no clue what hackernews is.
Sample problem (left pane blurry, right pane sharp - view at 1:1 scale on ~100dpi screen to notice it easiest, but it's quite visible to me with scaling even): https://i.imgur.com/Ju0UK2K.png
You act like this is a problem exclusive to Electron apps. People have been doing shit like that forever.
Make the window too small and the buttons overlap in the titlebar. I didn't even pick an extremely small size or anything, this was about half my screen width on my Macbook. But this is the kind of thing that making a proper native app forces you to think about, but that making an Electron app often doesn't.
http://i.imgur.com/MOaESLC.png
I can pretty much tell within a minute of starting an Electron app because things just don't feel right no matter what the app is. Sibling mememachine is also pretty accurate - Discord is very oversized like many other Electron apps.
Not using native platform widgets is also incredibly noticable. Every time you're not using native platform buttons or menus it's so easy to tell, it feels weirdly slow, has excessive gaudy animations, the spacing is wrong, text size is wrong, etc. That's not to say that it can't be done right just that you're on an existing platform and that consistency is key.
Qt is great but electron has certainly been getting better and better.
I have a 4 year old mac and VS Code goes from closed to a file opened in about 4 seconds. Still a stupid amount of time for a text editor, but no-where near 30.
While we're here, honest question: how do Electron-based apps fare in terms of accessibility (e.g. to screen readers like Orca) compared to native-based apps (GTK, Qt, MFC, Cocoa)?
Specially on mobile. their decision to go with QML for mobile OS support, requiring devs to replicate native widgets, means it is a bigger effort to create multiple QML frontends, than it is to follow a MVVM architecture with as much code as possible in C++, while using native support directly, even if in different languages.
Also for those targeting mobile OSes, Xamarin has a much support for the respective OS APIs than Qt, that usually requires the extra effort of manually wrapping many of them.
As someone that prefers working on native apps to web ones, I kind don't understand their current roadmap, it appears that they are trying to spread between C++ and JavaScript devs in an attempt not to lose mind share.
From your link it seems that by Qt 6, they might eventually get something that I already have with such setup today.
Also I am planning to switch to Xamarin in future side projects.
And maybe losing both camps in the process.
I just don't get it. The Qt app will be faster, better looking, better integrated with OS apis much saner to develop (QML is really productive and what react would be if it could have is own DSL).
Did you miss the point I mentioned I prefer native apps?
Working on web apps is unavoidable when that is what customers are willing to pay for, on my own private devices outside work hours, pure native applications are the rules of the house.
Spotify, even with much less features and a pretty simple interface, lags out every time I load it, for 10 seconds or so, and overall isn't very responsive. Thats on a pretty good system. Winamp does everything instantly.
I see things like Electron as a form of debt in technology. You can build things cross-platform really quickly, but you're taking out a lot more debt to do it, the problem is that the app can become so popular that they never pay it back.
its certainly possible to make slow native apps and fast electron apps. whether yours is fast or slow, and whether you can build it quickly only depends on your skillset
cf: winamp vs windows media player
When loading the UI takes 4 seconds. Pretty sure thats a problem, and its impossible to actually /prove/ its 'just their code', there is supporting evidence due to the technologies they chose and the nature of why they're used.
>whether yours is fast or slow, and whether you can build it quickly only depends on your skillset
The software you are using matters a lot, too. You can't just throw any tech at a problem and it'l solve it. Your skillset is dependent upon what you know, and how you know to use it, but is limited based upon what is available and readily possible. Chromium and node.js have overhead, and are very good at some things, and other things they are much worse for than a native app. Add ontop the crazy environment of JS and its inneficiencies for performance in comparison, and you get a big pile of mud. Useful, if you need to create something quickly, like many startups.
but is this the reason for a desktop music player to be lagging on a "pretty good system"? no way -- there's no real excuse for that. its just a shitty app. perhaps electron gives teams the impression they can just type npm in front of some stuff to turn their website into a performant desktop app -- not quite so ;)
The "ideal" solution would be to run the entire Qt/C++ application in the browser, as a static "web page." This is can be done using WebGL and cross-compiling C++ to asm.js/WebAssembly. There are several Emscripten demos showing exactly that, with an ancient version of Qt [1]. But I guess the Qt team has decided they don't want to support that direction (i.e. not even trying to port Qt5 to Emscripten, but instead offering this "WebGL streaming" thing)? Although, given how "heavyweight" Qt5 seems to be, I guess cross-compiling the whole thing to WASM would result in something very inefficient.
Personally, I have been troubled by Qt's recent direction. First there was the confusion of legacy QWidget vs. modern QML. A modern approach to UI specification is welcome, though I question the need for embedding a JavaScript engine when QML could have been compiled to native code. But the real issue with QML is that the legacy QWidget approach was never really depreciated, so Qt was no longer a coherent, unified approach to developing UIs. Qt5 looks like two completely different UI libraries combined into a confusing whole. The general spirit seems to be that desktop applications are a second-class citizen in Qt, relegated to using legacy QWidget framework, and the new QML framework is targeted towards mobile applications (the new first-class citizen). This is unfortunate because users run most professional applications on desktops with keyboard and mouse input, not on 6-12" touchscreens. More recently, they decided that the whole "Qt Quick Controls" line had terrible performance, so they were going to dump cross-platform "native look & feel" (the original raison d'être of Qt) in favour of a "Qt Quick Controls 2 [2]. Although, more recently, they seemed to be walking back that "native look" decision (making the roadmap even more uncertain) [3]. If the message to desktop developers wasn't clear enough already, the sparse list of "Qt Quick Controls 2" [4] components that have shipped so far are squarely aimed at simple mobile apps ("Drawer," "Switch," "SwipeView," etc) and is missing basic components needed to build a desktop application (for example, no promised release date for shipping a data table view component).
It turns out that this enormous edifice that has been built up, on top of Qt's native C++ roots, is incompatible with the future direction that web browsers are taking with WebAssembly and WebGL. While these browser developments are proving to be a great thing for bringing OpenGL native applications to the web browser [5], Qt seems to be left behind. They instead have to resort to building this "WebGL streaming" functionality on top of an already teetering stack, in order to deliver applications through the web in away that has obvious drawbacks.
In my opinion, the C++ community should move past the Qt legacy and come up with a new industrial-strength, cross-platform UI library that has simultaneous first-class support for web, desktop, mobile and embedded targets.
[1] http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
[2] https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-n...
[3] https://blog.qt.io/blog/2017/02/06/native-look-feel/
The "write-once-deploy-everywhere" never worked,especially across form factors and devices, I'd prefer Qt focusing on what it does best (desktop) instead of trying to be a "the least common denominator" that is broken everywhere. Each platform has its own UI/UX language, it's something one just cannot reproduce with a single framework. A Qt app feels like a Qt app, and that's fine on desktop. It's not on mobile.
They do want to support that direction; see Lars Knoll's "Qt Project Status" talk [1] from QtConf 2016. Talk about WebAssembly starts at 50:30 and also mentions the recently-introduced QtLite as a potential path to your concern of the "heavyweight" problem.
[1] http://ftp.icm.edu.pl/packages/kde-applicationdata/akademy/2...
I doubt it will ever happen.
C++ has become an infrastructure language for the lower layers of the OS and language runtimes of Apple, Google and Microsoft.
Microsoft is the only exception with UWP and C++/CX, with the alternative C++/WinRT scheduled for VS2017. Yet most of their Channel9 and BUILD GUI presentations make use of C# and VB.NET.
The only OS vendors other than Microsoft, that still offer C++ GUIs in their SDKs are the ones targeting the embedded market.
So that leaves Qt with their increasing love for JavaScript, wxWidgets or JUCE.
but... Qt5 already works in big part in Emscripten (with pepper.js). It's far from perfect, sure, but they've been working on it for a long time.
http://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-e...