What can be done with Only Qt , not with QML
-
@DonCoder That's a very strange question, because QML is a part of Qt. There is no Qt vs QML.
QML is a very powerfull language to create HMI (Human Machin Interface), but has very poor performances in computing. But because interfacing the QML with the C++ world is very easy, you can do all time consuming computing in C++ and handle the user interface with QML/JScript.
-
Thanks, @KroMignon. I marked it as solved as i agree with @KroMignon. But still, I am open to any suggestions and views you want to share on this
-
@Bob64 Perhaps you are right. In this case I cannot give a relevant respons, I am not very familiare with Qt Widget.
The only advantage I know, using QML instead of Qt Widget, is that QML will better match to target OS look and feel. Qt Widget always looks like Qt Widget application. It depends if you want to look like an Android/IOS/Windows/Linux application.
On the oder side, QML will require mutch more memory and also OpenGL support to work. -
@KroMignon said in What can be done with Only Qt , not with QML:
The only advantage I know, using QML instead of Qt Widget, is that QML will better match to target OS look and feel. Qt Widget always looks like Qt Widget application. It depends if you want to look like an Android/IOS/Windows/Linux application.
That's only partly correct. Qt Widgets will look native on desktop OS as they always had so well integrated on these platforms.. They work on mobile but are not optimised for that use case and will not look native there.
QtQuick can look native on desktop using the Qt Quick Controls module.
One main difference is that Qt Quick requires OpenGL for rendering while Qt Widgets not. As for memory consumption, it will depend on the release of Qt you are using. There has been lots of improvements performance wise with the latest releases.
The advantage of Qt Quick is that you can more easily create dynamic GUI (visual effects, transitions, etc.). However as always: use the tool that fits best yours case.
-
@KroMignon "Qt Widgets do not require OpenGL", No objection here but some questions. Qt Widgets will use Wayland if available and that will render via OpenGL, hence QtWidgets should render as fast as QtQuick. Is this assumption correct?
When it comes to writing QtWidget controls you use some simple 2D drawing primitives hence creating new QtWidget components is not too difficult and in fact there are tons of open source third party components for QtWidgets.
But creating QtQuick controls seems to be tricky. I hardly see new components being created, neither 3rd party nor from QtCompany or KDAB. Am I correct believing that QtQuick is a bad choice if you need to create your own controls (a PivotGrid fro example)? Is this because a QtQuick controls developer needs to be also a seasoned OpenGL developer?
Will QtQuick controls be created with something else other than OpenGL in the future (Qt3D for example)?
-
@Patrick-Fromberg said in What can be done with Only Qt , not with QML:
But creating QtQuick controls seems to be tricky
Why do you say that? I don't think it is more complicated to create a QtQuick component in comparison to QtWidget component.
For QtQuick, you can use QQuickPaintedItem() a base class. There is no need to be aware about OpenGL.
You can also create you component only in QML, this is what I do in most cases.
I use C++/QQuickPaintedItem() only when performance is required. -
@KroMignon , got the name wrong 8-(. Question was for @SGaist. But I am happy to discuss with you then 8-). When you say it is easy, how do you explain why in all these years hardly any additions to QtQuick Controls 2 are happening?
Recently I saw a blog announcing a new TableView Control 2. First, that is not much, second it was very basic (actually only a proof of concept) and third it was not even a QtQuick Control 2 but just a QtQuick Item.
Writing new Quick Controls via QML has its use cases but not for what I need. I cannot imagine creating a high performance high data volume PivotGrid this way, but please correct me if I am wrong, I have not written any app with QtQuick Controls 2 yet.
-
@Patrick-Fromberg I think you are talking about this post: https://blog.qt.io/blog/2018/08/29/tableview/
I am not the right person for such a question. I am a "basic" developer, I did not develop very complicated stuff with Qt/QML.
I don't think I have enough background knowledge about QtQuick/QML to give you a relevant answer.
But, no, QML is not the right way for high data volume handling. That's a fact!Perhaps you should try to send your question on the Qt mailing list :https://lists.qt-project.org/
-
Thanks Kro, did not know about that list, will have a look.
-
QtWidget uses the raster engine so it is CPU based. One exception is QGraphicsView where you can set a QGLWidget/QOpenGLWidget as viewport to get the painting accelerated through OpenGL.
Kirigami is a good example of QtQuick based framework.
-
@SGaist , I looked at Kirigami and it is inspiring from the user interface design perspective. I will keep an eye on it for this reason and maybe use it for super small apps.
However, looking at QtQuick I am more and more convinced that QtQuick may have a future but it is not the future that replaces QtWidgets (especially not for C++ developers). I am still puzzled and cannot find any convincing information on why QtQuick Controls 2 just do not progress. No TableView in half a decade!
Another experience from which I derive my conclusion is the WindowsForms vs WPF story. The two differ in similar ways as QtWidgets vs QtQuick do. But even though WPF is much stronger on the Control side compared to QtQuick it just fails to replace WindwosForms on the desktop and many people are actually going back from WPF to WindowsForms. Of course QML is way ahead of XAML but this is not enough to change the story.