What is QtQuick/QML really for?

[Huk]

Hello everyone.

This probably has been asked before, but I can't seem to find any straight answer. As I understand, QT5 will mark widgets as deprecated, and QtQuick will be recommended alternative from then on. But what is Quick really for? It seems to lack most standard desktop widgets, so how am I suppose to switch from widgets to Quick if there are no counterparts for most widgets? Or maybe I got something wrong, and widgets counterparts will be added in QtQuick2.0, or maybe widgets are not as dead as I think?

Can Quick be effectively used in standard desktop applications right now (with QT-4.8, and by standard applications I think of anything that use: filedialogs, scrollbars, databases etc.) or is it just fancy GUI creation tool that shouldn't be used for desktop applications?

Could somebody please explain this, because I am lost :/

Thanks for the answers and sorry for any language errors, English is not my native language ;]

[wysota]

As I understand, QT5 will mark widgets as deprecated

No, not really. More as a complete (as in terms of further work) module.

It seems to lack most standard desktop widgets, so how am I suppose to switch from widgets to Quick if there are no counterparts for most widgets?

First of all you don't have to switch -- you can continue using QWidget and family. Second of all, as far as I know, QtQuick will provide desktop components for QML, so you'll be able to use more or less the same things in both C++ and QML.

Can Quick be effectively used in standard desktop applications right now (with QT-4.8, and by standard applications I think of anything that use: filedialogs, scrollbars, databases etc.) or is it just fancy GUI creation tool that shouldn't be used for desktop applications?

That's a good question. I wouldn't call it a "fancy GUI creation tool", it can be really useful. Sometimes the same effect can be obtained in QML using 10-20 lines of code as using 500 lines of code in C++. However in my personal opinion, standard industry applications focused on data processing are better implemented using C++ since it'd be more work to make QML and C++ cooperate than to actually implement the user interface in Qt Designer or even using hand-written C++/Qt code.

[Huk]

@wysota:

Thanks for the answers, it's good to know that Quick will get widget counterparts... (You mean QtQuickv2.0 that will be in QT5, right?) still I fear that Quick will become the only supported GUI "API" soon, and widgets won't even get bugfixes, I hope I'm wrong here but...

Sometimes the same effect can be obtained in QML using 10-20 lines of code as using 500 lines of code in C++

I must say that I have read above statement many times - could You please give some example to support it? Don't get me wrong, I know that some things Quick can do (rotation, scaling special effects etc.) are very hard (or nearly impossible) to obtain with QWidgets, but this is still only GUI, so I wonder if there are other - non-GUI - applications, that Quick can speed up?

[wysota]

(You mean QtQuickv2.0 that will be in QT5, right?)

Desktop Components are also available for Qt4 (QtQuick 1.1).

http://labs.qt.nokia.com/2012/06/06/...ents-for-qt-5/
http://qt-project.org/wiki/QtDesktopComponents

still I fear that Quick will become the only supported GUI "API" soon, and widgets won't even get bugfixes, I hope I'm wrong here but...

I can only say what I read here and there what was said by Nokia staff -- bugfixes will be provided, however functionality of the module will not be extended by the current Nokia team. If someone (as in 3rd party) wants to add functionality to QtWidgets module, it should be possible.

Which basically means new fancy stuff written "in Nokia" will only be available for QtQuick.

I must say that I have read above statement many times - could You please give some example to support it?

Sure. A list view showing a fully clickable button and a progress bar (or anything else) for each entry. In C++ you need to implement a quite complex custom delegate for this using QStyle API for drawing the button and the progress bar (which is really hard for e.g. animated progress bars in Vista/7) and manual event handling for the button using QAbstractItemDelegate::editorEvent(), in QML it's just a couple of declarations (provided you already have components for the button and the progress bar).

so I wonder if there are other - non-GUI - applications, that Quick can speed up?

No, QtQuick is only about GUI. You should still implement the logic in C++ (or whatever else binding you are using). In theory you can implement a complete app using QtQuick (QML+JavaScript) however it will certainly not be as fast and as easy (in a general case) as if you have written it in C++.

[Huk]

Thanks again, I tried desktop components with QT-4.8.1 and can't get them to work, or rather, I can run example just fine, but I cannot modify it, or use desktop components in my own applications. Every time I try to import the "QtDesktop 0.1", i get "QML module does not contain information about components contain in plugin"... hmmm is there something more beside "make install" that need to be done in order to use the components?

Also, as far as I understand it desktop components won't be the integral part of QT5, just a plugin, which is pretty sad :/

[wysota]

Thanks again, I tried desktop components with QT-4.8.1 and can't get them to work, or rather, I can run example just fine, but I cannot modify it, or use desktop components in my own applications. Every time I try to import the "QtDesktop 0.1", i get "QML module does not contain information about components contain in plugin"... hmmm is there something more beside "make install" that need to be done in order to use the components?

I can't say right now, I don't have the components installed. You probably have incorrect paths somewhere.

Also, as far as I understand it desktop components won't be the integral part of QT5, just a plugin, which is pretty sad :/

Why so?

[Huk]

I can't say right now, I don't have the components installed. You probably have incorrect paths somewhere.

I think I will create separate thread for this problem.

Why so?

As for the other question - well, maybe I am overreacting here, but for me something that is so important to many people should be in the core. Plugin means that something is optional, and not as well supported, or worse - that it can be dropped at any moment.

I hope I am overreacting but,,, ;]

[wysota]

JPEG handling for QImage and QPixmap is also a plugin. I see that more as an advantage rather than a disadvantage.