Qt Quick Controls 2.1 and Beyond
blog.qt.io
blog.qt.io
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.
That means no Chromium or other bundled web browser with every desktop app.
With Qt, you app will be light-weight, blazing fast, and have a native look and feel (as Qt uses native widgets whenever possible).
http://doc.qt.io/qt-5/qtwebenginecore-module.html http://doc.qt.io/qt-5/qtwebenginewidgets-module.html
A nimble, feature-complete starter client that is fully scriptable with javascript, i.e. qmlscene without the rough edges, would be ideal.
[1] http://ovilab.net/projects/qt-emscripten/qml-sandbox/ [2] http://dragly.org/2016/04/27/experimental-qt-and-qml-in-the-...
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.
EDIT: Also, for anyone interested in Qt, the whole talk is worthwhile to get an idea of where Qt is going.
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.
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.
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.
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.
Related: Did they stop developing Qt Widgets?
Given that plus the QWS backend change with v5 and the new LGPL terms, I'm probably staying here for a long time to come.
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.
"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.
Am I missing something?
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.
http://doc.qt.io/qt-5/qtqml-cppintegration-interactqmlfromcp...
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.
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.
Or are you referring to LGPL?
[1] https://tldrlegal.com/license/gnu-lesser-general-public-lice... [2] https://www.qt.io/faq/#_Toc453700715
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.
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.
https://news.ycombinator.com/item?id=12653246
So for mobile platforms you can publish compiled .obj files.
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.
So it isn't any more?
If mobile isn't an issue then by all means wxWidgets!
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)
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...
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.
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.
Qt seems to be almost caught up with getting qt5 in the meta directories and having everything in place.
The automotive industry is notorious for hating to change what already works, after all.
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.
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.