Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QtQuick without QML ( pure C++ apps possible)
p8mode last edited by
Id really like if it were possible to use QtQuick purely with c++. Ie not just write the app logic with c++ and "bind" it to user interface code written in Qml, but write everything in c++ (but still leverage the advantages of QtQuick). After all there's no real reason why QtQuick necessarily needs QML.
As an aside RIM have made this possible by the way with their new Cascades framework for Blackberry 10. Developers have the choice of writing the ("qtquick") ui code in c++ or analogous qml. Great idea.
As I understand it QtQuick is the planned way of the future for user interfaces in Qt apps (and currently the only feasible way on mobile platforms like Symbian) with the QWidget based c++ classes destined for phasing out (or no real improvements at least).
So writing apps with a future especially on mobile platforms means saying goodbye to QWidgets and embracing QtQuick. (Personally I liked using the QWidget based interfaces, but QtQuick has its advantages too).
I hear a lot of people saying how great Qml is. In my humble opinion however Qml is fine for quickly prototyping applications. You can whip up an interface and basic logic elegantly with Qml as is often done by exponents. The problems arise (exponentially) when the size of the appp grows. I wonder how many of the people who think qml is great have written bigger projects with it. I had 12 years experience writing Qt apps (the first 10 for the desktop (using QWidget & co) which I loved, and the last 2 writing mobile apps using QtQuick, which I generally hated). Ive written several "real world" apps for the mobile platform using Qt (eg for Symbian Nokia N8, E7), my experience with which Im basing my comments here on.
And once youve bitten the bullet and decide to build all the ui with qml, you realise the quick and dirty techniques used to "glue" the qml to the c++ illustrated in the Qt examples need to be greatly improved upon. (Actually one would need a "framework" for binding the qml to the c++ satisfactorily). Here some of my experiences.. Generally I had a c++ controller class for each ui (qml) screen (sometimes also for sub components of the screen if they were complicated). The only way the qml screen and the c++ controller "know" about each other and can communicate with each other via handles which are strings. So one mistake in typing this string on either side means the app wont work and you get (no compile time error message but) just a runtime message if youre lucky which sends you off on a chase to find where you might have made a typo. Also these strings are global. There's nothing stopping you from inadvertently using the same strings for 2 different controller classes (which isnt going to work properly)...no error message, compile time or runtime. I tried to adopt and adhere to a strict naming convention for my c++ controllers and qml files/components, to make this less error prone (its not a great feeling when you reorganise your project and realise you need to remane files/classes .. have fun finding the "handle" strings you need to update).
p8mode last edited by
The amount of plumbing and "glue" code you have to write to bind the c++ code to the qml becomes more and more cumbersome the bigger an app gets. This would not be necessary if one could write everything in c++.
In your IDE you're used to being able to navigate easily between classes/objects and functions thereof. Its a nightmare repeatedly trying to figure out in a big project which qml file exactly belongs to which c++ controller and where's the definition in qml of the function the c++ controller is trying to call..your naming convention and app wide searching for strings is the only thing that can help you..no double click to jump there with qml involved. Then theres the performance issue...!! A real world app has a lot of qml files and the even a moderately sized one takes ages to initialise if its using qml. For one of our apps which had about 30 QML files (this isnt really a lot ... especially with each qml "component" generally in a file of its own), our app needed about 40 seconds to initialise. Yes, extensive testing showed that 37 of these seconds was just the Qml engine loading the qml! This is unacceptable. What user of a mobile phone would be happy with an app that needs the best part of a minute to initialise? Even if the qml engine was greatly improved, having to parse and interpret qml is always going to be much slower than running precompiled c++ code. And this performance issue is all the more important on mobile platforms where hardware is a premium..making the most of it matters.
Theres also just too much "magic" to QML. Things work because of matching names, this name/string appears in this position in such and such a file, or because this block is enclosed in parenthesis here .... things that are very hard to document or find in documentation if they were. C++ has (complicated but) clear rules.. you learn them and you can be sure of whats hapening. This lends to extensibility and robustness. With QML its more like witchcraft and hoping youll be lucky.
Im sure Qml has its good sides too (especially for rapid prototyping), and Im not trying to knock it in and of itself, but I would be delighted to see Digia make it possible for C++ developers to continue to use C++ (and only C++ if they choose) for Qt applications. If this means using QtQuick instead of QWidget based uis (which never worked on mobile devices yet and presumably will not be reworked enough to do so) then this probably means allowing developers to choose to write the QtQuick code in C++ (as well as alternatively in qml).
This topic was "recently":/forums/viewthread/16321/ "discussed":/forums/viewthread/16465/ ad nauseum in the forums. While passions run high on this issue and there are good points to be made by all parties involved, the short answer is that a QML-less Qt Quick is not on the immediate Qt roadmap. With that said, I'm sure the community at large would welcome code which leads to this implementation.
Edit to add: If we're going to discuss this more, let's all try to keep this civil and constructive.
justin1122 last edited by
An old topic, but I bookmarked this post years ago and was amused to find myself still agreeing with post, albeit I found that by using enums in qml and C++ I was able to avoid sharing strings between the two as much.