Should I use Qt or QML for my desktop application?

[Abdeljalil]

I know this question has been asked before, but I thought if I explained my own scenario I might get more helpful answers. Plus, I'm new to Qt, so I have a few additional questions as well. I recently took up Qt for cross platform UI development, but became frustrated when deciding between QtQuick and Qt Widgets. I'm looking to build a desktop application with smooth animations, written entirely (or mostly) in C++, and deployable without the need to install a framework.

I like QML due to its similarity to WPF, but quickly realized its more geared towards mobile platforms. I found that all textareas hid the standard 'I' cursor, and I couldn't even select text with my mouse. The text areas, as far as I could see, didn't even have a background property. I also found that by default, onClick events and such are encouraged to be written in Javascript, not C++. Yet, I find it very easy to create animations in QML.

Qt Widgets, on the other hand, I read is more geared towards the desktop, but I fear it will be like WinForms and the animations will be complex and jotty, and there is no easy way to implement animations in Qt GUI.

I also read that Qt Widgets is compiled, yet QML is interpreted by the framework at runtime. Is this true? I figured out how to statically link Qt to my projects, but I'm still not sure this fixes anything in the QML regard. From what I've tried, I think QML is still interpreted at runtime. I also read it can be slower, too.

In your experience, which do you think I should go with? Any help is appreciated. Thanks!

[d_stranz]

My understanding is that QML is interpreted when first encountered, then converted into something like bytecode for subsequent rendering. It's built on top of OpenGL and has been optimized for speed. The QML will be interpreted regardless of how you link Qt. The QML files would have to be linked in via Qt's resource system if you don't want to deploy the QML source files themselves.

Qt widgets might use OpenGL rendering, depending on the widget and Qt version. With Qt 5, the rendering has been abstracted into a platform-dependent DLL which must be deployed along with the app. I'm not sure if this can be linked statically.

I think animations will be good in either implementation. I personally use Qt Widgets for my GUI. When I first experimented with Qt 5.0 QML, I found it too primitive. With later releases of Qt 5, I think QML has improved substantially, but I'm not yet ready to tackle the learning curve needed to use them effectively.

If you're just starting in Qt, I would look at what each tool set has to offer. Widgets are very mature and offer a comprehensive set of features that don't require you to add much code to build a complex GUI. QtQuick is still evolving and getting more mature with each release and might now have all you need for your app.

My major personal issue with QtQuick is the one that's touted as its advantage: the separation of GUI from program logic. For the same reason I don't like defining signal/slot connections in the .ui file, I don't like my GUI actions spread between QML and C++ files. This might be because I don't see how I could use QtQuick to develop the entire GUI for a complex desktop application and end up with a mix of QtQuick and Qt Widgets.

[anda_skoa]

I know this question has been asked before, but I thought if I explained my own scenario I might get more helpful answers. Plus, I'm new to Qt, so I have a few additional questions as well. I recently took up Qt for cross platform UI development, but became frustrated when deciding between QtQuick and Qt Widgets. I'm looking to build a desktop application with smooth animations, written entirely (or mostly) in C++, and deployable without the need to install a framework.

In general I would go with QtWidgets for now, QtQuick.Controls are still a bit edgy.



I found that all textareas hid the standard 'I' cursor, and I couldn't even select text with my mouse.

Selection by mouse should definitely work.



The text areas, as far as I could see, didn't even have a background property.

See TextAreaStyle



I also found that by default, onClick events and such are encouraged to be written in Javascript, not C++.

You can call right into C++ in the signal handler.
I personally wouldn't write anything complex inside the JavaScript part, only things like changing another UI components state when that can't be done with a property binding for some reason.



Yet, I find it very easy to create animations in QML.

True. QtWidgets also has these animations but the declarative code is much more obvious IMHO.



Qt Widgets, on the other hand, I read is more geared towards the desktop, but I fear it will be like WinForms and the animations will be complex and jotty, and there is no easy way to implement animations in Qt GUI.

There is QPropertyAnimation which works very similar.
And of course one can use QML to create a QWidget scene, QWidgets are QObjects subclasses after all.


From what I've tried, I think QML is still interpreted at runtime. I also read it can be slower, too.

The "slow" part is usually just the creation of the object tree, which always happens at runtime, even with widgets (instances are always create at runtime).
It can be slower if too much is done in JavaScript.

Cheers,
_

[wysota]

I like QML due to its similarity to WPF, but quickly realized its more geared towards mobile platforms. I found that all textareas hid the standard 'I' cursor, and I couldn't even select text with my mouse. The text areas, as far as I could see, didn't even have a background property.
You could have a look at QtQuick.Controls. There are good and bad sides to it but if you don't need custom widgets based on regular widgets then it should be sufficient for you.


I also found that by default, onClick events and such are encouraged to be written in Javascript, not C++.
You can expose any QObject-based C++ object to QML and call its slots from QML event handler.


Qt Widgets, on the other hand, I read is more geared towards the desktop, but I fear it will be like WinForms and the animations will be complex and jotty, and there is no easy way to implement animations in Qt GUI.
It's not that bad. There is the Animation Framework available (have a look at QPropertyAnimation as already advised) and if you really really want then you can expose your widgets to a QML engine and implement the animations there. However the latter requires some knowledge on QML itself.


I also read that Qt Widgets is compiled, yet QML is interpreted by the framework at runtime. Is this true?
Partially. First of all there is a compiler available for QML in the commercial package which parses the documents at compile time and generates binary code for it. Second of all, AFAIK, QML engine is JIT-enabled which means that once objects are created and script is parsed, the engine can compile parts of the script on the fly to binary form and execute them just like it executed regular C/C++ code. JavaScript itself yields a number of other optimizations which allow you to write code which is more efficient than C++ and allows the engine to execute it more efficiently than it would run a precompiled function. So all in all performance depends on what you do in the script and how you do it.


I figured out how to statically link Qt to my projects, but I'm still not sure this fixes anything in the QML regard.
Statically compiling a program may only reduce its load time but it has no influence on performance once the program starts executing.


In your experience, which do you think I should go with? Any help is appreciated. Thanks!
It really depends WHAT you want to do and what your requirements are. If you want a fairly static and complex regular UI then it will be easier to do it in C++ even if you have to imperatively program all the animations as you will avoid having to learn QML. If you are worried about computation efficiency then you should certainly implement computation-intensive parts in pre-compiled language and the technology used for other parts of the program will again depend on the remaining aspects of your requirements. If you want a highly dynamic UI which at the same time is not very complex and you are not afraid of spending time to learn a new tool then I'd give QtQuick a try.