I dream of the inverse of the react native or electron trend. In this world one would write his application using Qt Quick for all the platforms including the web! Using Emscriptem you would be able to compile your C++ code to asm.js or webassembly and make your application run flawlessly in your browser with WebGL, canvas or HTML5 as a backend. Some people already started working on that: https://blog.qt.io/blog/2015/09/25/qt-for-native-client-and-...
Even using React, Redux, flexbox layout and all these fancy frameworks, I still find the web stack a huge hack that tries to bend HTML and CSS to recreate the feeling of an app (like SPAs). QML is simply more expressive for layouts and bindings.
Here is a demo of a QML sandbox in the browser using Qt+Emscripten if you are interested[1]. And the blog post in which I wrote about it[2]. It's quite big and not very well performing, but Qt might be useful for larger web apps one day.
Funny, I recently looked into using QML & Qt Quick as a lightweight alternative to electron, and although there are some promising factors with the approach, it became apparent that things would take a lot more work and experimentation than simply using electron.
A nimble, feature-complete starter client that is fully scriptable with javascript, i.e. qmlscene without the rough edges, would be ideal.
Is this due to unfamiliarity / learning curve with the technology or limitations found using Qt Quick? Because what you're describing sounds an awful lot like the base example when starting a new Qt Quick application project.
Not if you don't explicitly link against the relevant modules. That is usually done by adding a few entries in the Qt project file (qmake) and then including the headers.
The work in the Qt camp is simply amazing. I just wish there were more stable bindings out there for it outside of the official C++ one and PyQt (commercial or GPL, PySide 2 is not stable last I checked).
There's a promising Qt binding for Go[1] which I'm looking forwards to, but again, if I had to write an application and not want to struggle with the bindings I'm forced into the previously mentioned options.
It would be awesome to have a clean way to develop on Android with Python. Technically it is possible and has been done with Necessitas, but would be awesome if they can get it streamlined into their mobile Qt stuff.
I think the VFX industry is rallying that cause. Years ago Autodesk ported many of their 3d packages home-grown UIs to Qt (Maya and Max) I'm sure part of the goal was to reduce their maintenance burden and assist with cross-platform support. They also have Python runtimes that allow GUIs with Qt. They moved from PyQt to PySide a few years ago, too. In addition to Autodesk, The Foundry's Nuke and SideFX's Houdini are in the same camp. I've heard they're (specifically Autodesk is) funding the development and the vendors are all working together and have deadlines in place for their own annual releases.
Everyone is using Python 2.7 and have stuck with Qt 4 because Qt 5 hasn't really offered any compelling features for them. I believe the dropping of support for Qt 4 spurred them to push for Qt 5, hence PySide support for it. There are early talks about Python 3, but that's a few years off.
While I think bringing PySide back would be great, I use PyQt from day to day, and it works really well. Commercial PyQt licenses are reasonably priced, and it's dual-licensed GPL if you've got an open-source project or you just want to try something out.
That might have changed in 10 years (and the economics might differ for a small place), but when the place I was working was looking at switching from Perl/Tk for internal tools, they went with Python wxWidgets over PyQt4 because of licensing cost even though Qt would have been a better fit. They eventually went with PySide when that got released.
Meh. After trying to write real-world programs using bindings like MacRuby and PyObjC and probably others I've long forgotten, I'm convinced it's really not worth it compared to just using the blessed language of whatever platform. In Apple's case ObjC & Swift, in SDL's case C or C++, in Window's case C++ or C#. They're mostly the same for any practical purposes. All the smaller features that distinguish them are either quick & easy to learn, or just generally not worth using (I'm looking at you, Ruby's horrifying monkey-patching system!)
PyOtherSide is a very nice option if you want to (or can get by with) using QML for the UI. Since it's a "bridge" instead of bindings, there's no inherent lag or instability ascpect to it.
yeah, it's sad how hard it is to make qt bindings. this may be shallow of me but i use c++ at work all day, and i want to use something more fun to program in for my personal projects.
To anyone with experience building apps with QT: Would you recommend using it for new apps over Electron? I know the tech stack is different and I'm aware that Electron apps are all memory hogs which is why I wonder whether QT is a good alternative in Desktop or not.
I certainly would. Qt is fantastic. Not only will your app be faster, but depending on which type of Qt you use (Qt Quick controls 1, Qt Quick Controls 2 or Qt Widgets) it can also look native. I also like the UI and event model better than HTML+JS. Plus you even get a visual GUI builder.
I would recommend going with Qt over Electron any day. You'll have an app that's fast, responsive, easily be multi-platform, have the look and feel of a native app on every platform (Windows, macOS, Linux), is light-weight, doesn't hog a lot of memory.
You'd also not be trying to twist and bend over backwards to try to use something that was designed to display documents (HTML and DOM) to construct apps (with all the overhead that comes with it), and instead be building atop a framework that was created with desktop applications first and foremost.
What a lot of people don't seem to realize about Qt Quick (as apposed to using C++/Qt Widgets), is that it's like a game engine. People seem to think its akin to HTML and JS, i.e. 'interpreted' scripting language, but QML is actually more like a game engine language, it loads the assets into high performance GPU and has much better performance characteristics then anything else including the C++ widgets in many cases.
I haven't noticed our cross-platform desktop app to be anything but nice and lean.
I'd recommend Qt not only for desktop GUI work but would also recommend it even a bit more for general cross-platform stuff, i.e. our console apps are Qt as well and it's great.
One very good reason to use Qt is QML. It's just such an amazing language to work with for creating GUIs and is also a great way to learn declarative programming. And it is easy to mix QML with logic in either Javascript or C++ if you want to. Every time I work with anything else, like HTML+CSS, I just miss working in QML.
I don't have a lot of experience with Electron apart from working on some Atom packages. Electron seems like a good choice to me if you have existing code or libraries in JS that you want to reuse. Or if you want to make a combined web+standalone app. But if you want something that's fast, cross-platform and fun to develop, I would go for Qt.
A few months ago I was at a conference where Qt representatives were saying something to the effect of, "We have completed development on Qt Widgets." They were very clear that there were no current plans to deprecate them. Just that no new development was planned.
This was a conference for the VFX industry and the people in the room mainly wrote tools for 3d packages. So we had no interest in QML and just wanted native dialogs and widgets to automate things.
I'm from the VFX industry. I have a hard time understanding the logic of your last sentence.
"just wanted native dialogs and widgets to automate things" is pretty much exactly the benefit of QML in the way I use it for production tools. It's certainly an improvement over multi platform compiling, and onerous build cycles or way out of date python integration.
Quick, non-product oriented, tool development would in my mind be faster and easier to deliver to tight production timelines via an easy to edit document in a performance oriented declarative UI language over having to write fully compiled application UIs that are affectively hard coded. QML is a high performance easy to edit 'scene' file that is in effect a game engine level description for GUIs.
I didn't mean in any way that QML was a worse solution than what qt4 offers. More that it's not accessible (not shipping along with current 3d software) so it is off the radar for most people. 6 months ago I was at a place where all code had to be compatible with Python 2.6 (we had moved off of Python2.5 only a year or so before). When I've looked at playing with PySide2 using Python2 I see that it's not there yet.[1] I feel like I'm in the minority of people I work with who have even seen Python3, let alone know what features it has. At my current place we don't compile anything.
Most of the work I see are forms, running inside 3d software, that are basically arguments for a process...maybe read from a database or your local scene/environment. Designer UI files or hand-written UIs seem to be good enough for most people (it's way better than the alternative scripting UIs used before Qt). It needs to run inside and outside of Maya and other packages, which usually means is compatible with Python 2.6 and 2.7, likely need to support PyQt and PySide, and might need to work in Linux and Windows (ideally following that OS' conventions). Performance isn't a huge concern since loading the data takes way more than drawing the UI. Also, people are really averse to learning a new language.
The understanding I had for qt5 was focusing on UI elements for alternate devices like cellphones and touch. While a lot more flexible, in many cases you'd have to reimplement normal UI widgets from lower-level pieces. At the same meeting, the few people familiar with QML were asking about getting a QML Tree View.
I'm curious to know more about qt5, but like Python3, it's currently not an option.
I'm personally fine with QML (under the constraints the app I'm working on has to live with), but know that you're not alone.
There's a flamewar^W discussion happening right now in the qt-interest mailing list [1] under the name "[Interest] What don't you like about Qt?".
Your concern (the lack of a pure-C++ path for QtQuick Controls) is one of the most recurring pain points. Feel free to chime in if you have something to contribute. Qt folks are listening and do answer to well-formed arguments.
I would love to use Qt for personal for profit projects, but at $79/month (the cheapest commercial option) I find it too expensive, as a independent developer with pet projects that might not generate much (if at all).
What other good options do you know for building multi-platform nice-looking desktop UIs, I dont want to go with electron but so far is the best option I see for fast and cheap development, with the tradeoff of 50mb simple apps and not so great performance.
I'd love to see some evidence to back your claims regarding mobile platforms.
To satisfy LGPL, your users need to be able to swap Qt versions. For desktop platforms, that's trivial to do: Use dynamic linking and your users will be able to fiddle with the shared library files to their heart's content.
However, for IOS or Android, the moment the user changes the contents of your package, your signature is void and the vanilla platforms don't let the user install modified versions of your binary. For IOS, there are additional hurdles like the requirement to statically link or the licence incompatiblility when interfacing with IOS which to me boils down to this: If you are distributing a non-free app built with Qt Open Source via Google's Play Store or Apple's App Store, you are in violation of the terms of Qt's license.
The fact that the Qt company tries to play nice with the industry doesn't make it any less so.
I'd love to be proven wrong, but I'm just tired of watching this subject being discussed with nothing more than handwavy arguments, winks and smileys.
100% correct. Far too many misinterpretations of the LGPL out there seem to ignore the requirement that the LGPL'd portion must be able to be replaced/updated.
I've seen way too many LGPL-licensed embedded-C libraries and VHDL libraries where it just does not make any sense. If your target platform doesn't have a dynamic linker, then LGPL is the same as GPL. There are some hacks where people distribute unlinked .o/.obj files. This is acceptable as well, but I don't see it too often.
AFAIK you'll have to have a GPL your code right? If you want to keep the source closed, then you'll have to get a commercial license which costs money. Can you refer me to where you saw that you can use Qt for free with being able to keep your source closed? (you still can monetize open source programs so there's that)
The licensing has changed a bit over the past year. The biggest difference between the LGPL and GPL versions is that Charts and Data Visualization aren't available under LGPL, and Qt Quick is limited to OpenGL.
Qt is LGPL (3 ?), so you can use it for closed source proprietary projects assuming that it is possible to re-link your project (with Qt). I.e. you should use Qt as .so/.dll dynamic lib for desktop apps. For Android it is same as I understand. As for iOS - where as I remember you have to build static binary - just providing your .obj files is enough. So it is compiled, not open source.
If you use dynamic linking and target open platforms, like desktops, you can easily fulfill all the terms of the LGPL [1] without releasing your own code. See 3.7 of the Qt Legal FAQ [2].
It's confusing as hell what you can actually do with it... Even talking to Qt sales, it is a little fuzzy on what is allowable or not.
But in general yes, you can create commercial products as long as you don't modify their stuff or link to it improperly or look at it wrong.
I'm a Qt developer with 10 years under my belt and I still can't figure it out.
But something has radically changed with the new LGPL licensing in recent versions, from what I can tell.
I recently received an RFP from a very large European vehicle manufacturer, the RFP requested that Qt 5.6 should be used and no later. (The licensing changed with 5.7, so their lawyers must have figured this out)
LGPLv3 includes the "anti-TiVoization" clauses which require that any device including the software must include an offer for not only the covered source code, but "Installation Information" allowing the end-user to replace the firmware on the device.
Giving out this info is not something that a car company (or really any companies) want to provide.
It's unfortunate that a large car company doesn't want to buy a commercial license, but maybe they'll be forced into that once 5.6 becomes too old.
Can you clarify how that differed from the previous open-source license?
I thought, prior to 5.6, you could go licenseless if you provided a way for the user to replace the (dynamically linked) Qt libraries with libraries of their own.
Was it just too nebulous before, and most companies just didn't offer a way to do this or buried it in some backdoor or something?
Yeah, I agree it's a shame that a lot of companies don't want to license up, but if you've seen what they want for a per-device fee these days you'd probably understand. I did a product in 2008 and it was maybe $1/unit, now it's an order of magnitude larger.
Yes, that's generally the spirit of both the LGPLv2.1 (5.6 and before) and LGPLv3 (5.7 and up). Link dynamically to the LGPL covered libraries, provide the source, and you're good.
But there's a commonly-used loophole: the LGPLv2.1 does not state that the user needs to be able to actually replace the covered library with their own built binary. In 1991/1999 this may have been assumed (given dynamic linking and desktop OSes), but for embedded devices and newer platforms it is not a given.
Digital signature verification can be used to prevent the user from loading their own firmware (the only way of replacing the LGPL libraries). This is why the GPLv3 added the anti-TiVoization clauses, requiring that installation instructions be provided with the source code, so the user can actually install the libraries onto the device.
I'm in final test on a 4.8-based product and actually put in a backdoor to replace the libraries...just to be safe and compliant. Guess the work isn't totally wasted.
That sounds concerning, I would really like to know more about what that really means.
I briefly started investigating the changes for Qt 5.7 before I started having flashbacks of trying to figure out all this LGPL stuff again. Does not seem to be any less confusing...
My team didn't take the proposal, but from what I gathered during some fact-finding the 5.7 terms changed what you need to distribute to customers regarding the Qt libraries.
Before, you had to maintain a Qt source repository that matched distribution. People could build and link in Qt as they pleased, either vanilla from that repo or modified as they liked.
With 5.7 and the new LGPL, it seemed that you also have to provide the entire toolchain needed to build the source and link it into the final application. Which means you also need to provide the kernel headers and etc that match up.
I could be totally wrong. But I'm guessing 5.7 required too much other stuff be made public and the customer wasn't pleased with that. Can't say I disagree.
It's the same anti-tvoization stuff as GPL3. Companies were giving out the source code, but used locked down hardware or proprietary toolchains so the source code was useless. What LGPL3 specifies over LGPL2 is that the source code needs to actually be usable. The spirit of that rule rather makes sense to me.
Of course, part of the reason why The Qt Company likes LGPL3 is that other companies are going to look at the requirements to use and distribute open toolchains for their supported platforms and just buy a commercial license instead.
The funny thing is that the Yocto project has kind of eliminated a lot of the hurdles. You could technically branch a .bb recipe for your kernel and boardset and everything else would build on its own, including the SDK with toolchain wrapped in.
Qt seems to be almost caught up with getting qt5 in the meta directories and having everything in place.
I've seen even legal departments get scared from some of these licenses, but it's not that complicated. GPL requires that you license ALL your code as GPL as well. LGPL lets you link against a so-licensed library without affecting the license for the rest of the software.
The approach I use on my hobby projects between Android and WinRT (nowadays UWP).
A MVVM architecture with the business logic in C++, and views written in Java, C++/CX.
It used to be less effort than trying to make Qt look like native UI, while at the same time having to write wrappers for the platform APIs not supported by Qt.
Other alternative I am now looking into, is moving into Xamarin.
I do the same for my apps, but with a Python "backend". It allows me to use Python on my webapps, and Python on Android through JNI and Java on the frontend (https://github.com/joaoventura/pybridge)
"Dear ImGui" (https://github.com/ocornut/imgui) is an absolute delight to use. Can't recommend it highly enough. It's not suitable for every project, but when it does fit then I can't think of anything else I'd rather use.
I know Qt Quick Controls 2.x focuses on mobile, but I'm still waiting for it to get a native look-and-feel on the desktop. Qt Widgets is near-perfect if you want native look-and-feel across desktop platforms, but since all the focus is on Qt Quick, the future of Widgets is unclear. Qt Quick Controls 1.x also had native look-and-feel, but (as far as I know) no support for high-dpi on Windows and Linux, making it strictly less useful than Qt Widgets 5.6+, and like Qt Widgets, its future is also unclear.
I'm looking for some references to QT / QML guys to help us along on our project that's very much active. Bonus points if you have multimedia pipeline experience! E-mail: jordan(at)evasyst(dot)com
I've only built front ends in QtCreator and Visual Studio WPF, but after getting over the initial QT way of doing things, I find it delightful. It's C++, though. So it's definitely weird in that uniquely weird C++ way.
Even using React, Redux, flexbox layout and all these fancy frameworks, I still find the web stack a huge hack that tries to bend HTML and CSS to recreate the feeling of an app (like SPAs). QML is simply more expressive for layouts and bindings.