Is it possible to use Qt Quick modules without QML?
-
As per topic, is it possible to use Qt Quick modules without QML?
I read that QWidgets is very bad in performance for Android, and it seems that QML/Qt Quick is the way to go. The thing is that I tried i and for several reasons, I just prefer a C++ only approach. Is there any way to use Qt Quick modules without having to use QML? if not, at least a plan to implement this "feature" in a future release?
-
Not possible as of today. QML is the interface. Not sure about the "feature" in future releases.
-
Not possible as of today. QML is the interface. Not sure about the "feature" in future releases.
@dheerendra I understand, thank you for your reply.
-
As per topic, is it possible to use Qt Quick modules without QML?
I read that QWidgets is very bad in performance for Android, and it seems that QML/Qt Quick is the way to go. The thing is that I tried i and for several reasons, I just prefer a C++ only approach. Is there any way to use Qt Quick modules without having to use QML? if not, at least a plan to implement this "feature" in a future release?
@Sandon said in Is it possible to use Qt Quick modules without QML?:
Is there any way to use Qt Quick modules without having to use QML?
I think you could get pretty close.
You can use C++ to implement your own sub-types of
QQuickItem, which are scene graph items in the QML scene.You would still need something like a
main.qmlthat specifies (for example) a full-screen layout containing only yourQQuickItemorQQuickItem(s).Refer to: https://www.kdab.com/writing-custom-qt-quick-components-using-opengl/
I suspect that if you started to make progress with this approach, you would also start to notice that adding a few more pure-QML items to the layout is going to be quicker, easier, and possibly more maintainable, and you might find yourself using more QML and less C++ (for layout) as you go forward.
If one of your main concerns is being able to unit-test (or otherwise automatedly test) your C++ in ways that C++ testing advantageously makes possible whereas QML test features might be lacking, then please consider:
-
it is possible to keep your QML purely declarative and purely layout/view-oriented (no business logic)
-
one way is described here: https://forum.qt.io/post/666155
-
-
Thank you guys. These answers were what I was looking for. Very very informative and interesting.
Ideally I would have preferred something a-la-QWidgets, purely C++, but it seems Qt does not view it like me (and others).
Yes, one of my concerns is unit-testing, but I have many more ones. At this time, I would like to treat Qml considering it as a kind of declarative configuration file, with near-zero logic. From docs and examples it does not seem an easy task, but we'll see how that will go.
I have nothing against QML. I think it may be very useful, especially with people with not much experience in C++ or for small projects. For seasoned C++ developers and for larger code bases founded on reuse and continuous refactoring, in my view, it is a no go.
-
@Sandon said in Is it possible to use Qt Quick modules without QML?:
Is there any way to use Qt Quick modules without having to use QML?
I think you could get pretty close.
You can use C++ to implement your own sub-types of
QQuickItem, which are scene graph items in the QML scene.You would still need something like a
main.qmlthat specifies (for example) a full-screen layout containing only yourQQuickItemorQQuickItem(s).Refer to: https://www.kdab.com/writing-custom-qt-quick-components-using-opengl/
I suspect that if you started to make progress with this approach, you would also start to notice that adding a few more pure-QML items to the layout is going to be quicker, easier, and possibly more maintainable, and you might find yourself using more QML and less C++ (for layout) as you go forward.
If one of your main concerns is being able to unit-test (or otherwise automatedly test) your C++ in ways that C++ testing advantageously makes possible whereas QML test features might be lacking, then please consider:
-
it is possible to keep your QML purely declarative and purely layout/view-oriented (no business logic)
-
one way is described here: https://forum.qt.io/post/666155
@KH-219Design Hi,
As you brought up qml testing topic.
I have many doubts.
Can you explain how to do unit testing to qml pages?
And how to get coverage report for this.If possible can you share a resource.
-
-
Thank you guys. These answers were what I was looking for. Very very informative and interesting.
Ideally I would have preferred something a-la-QWidgets, purely C++, but it seems Qt does not view it like me (and others).
Yes, one of my concerns is unit-testing, but I have many more ones. At this time, I would like to treat Qml considering it as a kind of declarative configuration file, with near-zero logic. From docs and examples it does not seem an easy task, but we'll see how that will go.
I have nothing against QML. I think it may be very useful, especially with people with not much experience in C++ or for small projects. For seasoned C++ developers and for larger code bases founded on reuse and continuous refactoring, in my view, it is a no go.
@Sandon said in Is it possible to use Qt Quick modules without QML?:
For seasoned C++ developers and for larger code bases founded on reuse and continuous refactoring, in my view, it is a no go.
Reuse and refactoring the UI is where QML shines. It forces you to have a proper and clear interface between your business layer and your UI layer. You can refactor one with little to no impact to the other.
I'd say I'm a c++ seasoned developer (and I also believe my peers would say that) with more than 10 years of professional Qt experience, I've written a lot of QWidgets code before switching to QML a long time ago and I don't see what your opinion is based on.
C++ is best kept where it matters, and that's not in the UI. There's no added benefit to have boilerplate and complex c++ code for your UI when there is a declarative language designed from the ground up for it. With qmllint and QML to c++ compilation in Qt 6, the talking points for QWidgets shrink further. -
First of all I'd like to say that you may be right as I do not well the technology. The thing is that my gut tells me that this is not the case.
Reuse and refactoring the UI is where QML shines. It forces you to have a proper and clear interface between your business layer and your UI layer. You can refactor one with little to no impact to the other.
Who says I can't do this same separation in C++? who said I wouldn't need to do large refactorings involving both UI and core?
I'd say I'm a c++ seasoned developer (and I also believe my peers would say that) with more than 10 years of professional Qt experience, I've written a lot of QWidgets code before switching to QML a long time ago and I don't see what your opinion is based on.
I do not doubt you have a lot of experience and I believe different people like different things. I tried using .ui files and co, but my experience tells me that they do not scale well for large applications, especially when your goal is to create configurable and generic items used in different applications.
C++ is best kept where it matters, and that's not in the UI. There's no added benefit to have boilerplate and complex c++ code for your UI when there is a declarative language designed from the ground up for it. With qmllint and QML to c++ compilation in Qt 6, the talking points for QWidgets shrink further.
In my opinion "boilerplate and complex" is the process to use QML. Ok, there are things that you can do in QML that you cannot in C++, but if I were worried about that I wouldn't be using C++. C++ is so powerful for UI, and who said that the complexity needs to be visible? it will just need to be demoted to low level libraries. Better then not to speak about performance, compile time capabilities and so on
-
Thank you guys. These answers were what I was looking for. Very very informative and interesting.
Ideally I would have preferred something a-la-QWidgets, purely C++, but it seems Qt does not view it like me (and others).
Yes, one of my concerns is unit-testing, but I have many more ones. At this time, I would like to treat Qml considering it as a kind of declarative configuration file, with near-zero logic. From docs and examples it does not seem an easy task, but we'll see how that will go.
I have nothing against QML. I think it may be very useful, especially with people with not much experience in C++ or for small projects. For seasoned C++ developers and for larger code bases founded on reuse and continuous refactoring, in my view, it is a no go.
@Sandon said in Is it possible to use Qt Quick modules without QML?:
At this time, I would like to treat Qml considering it as a kind of declarative configuration file, with near-zero logic. From docs and examples it does not seem an easy task
You can do it. This is how I treat QML. Purely declarative. No loops. Very few conditionals. (And the conditionals are usually "change the color based on one boolean that is provided from the C++).
You can do it.
Don't be too discouraged by any impression you get from documentation.
Documentation for many frameworks (not just Qt) tends to suffer from ... searching for a good phrase... "lack of imagination" (?) ... or "lack of ambition" (?)...
I think for many frameworks, it is just very hard to write documentation that explains how to craft a production-grade solution in the framework. Docs cover little zoomed-in "bullet points" of "how to use this class" (but in very basic ways) and "how to use this other class", but docs rarely (or never?) give a great vision for how to build a gigantic production app in a sane way. (Maybe that's what some books attempt to do? But I don't have book recommendations to offer on QML.)
Keep your wits about you and apply general separation-of-concern and testability principles. Use good software craftsmanship. If you do that, you can get what you want with QML. You can keep business logic out of the QML.
-
@Sandon said in Is it possible to use Qt Quick modules without QML?:
At this time, I would like to treat Qml considering it as a kind of declarative configuration file, with near-zero logic. From docs and examples it does not seem an easy task
You can do it. This is how I treat QML. Purely declarative. No loops. Very few conditionals. (And the conditionals are usually "change the color based on one boolean that is provided from the C++).
You can do it.
Don't be too discouraged by any impression you get from documentation.
Documentation for many frameworks (not just Qt) tends to suffer from ... searching for a good phrase... "lack of imagination" (?) ... or "lack of ambition" (?)...
I think for many frameworks, it is just very hard to write documentation that explains how to craft a production-grade solution in the framework. Docs cover little zoomed-in "bullet points" of "how to use this class" (but in very basic ways) and "how to use this other class", but docs rarely (or never?) give a great vision for how to build a gigantic production app in a sane way. (Maybe that's what some books attempt to do? But I don't have book recommendations to offer on QML.)
Keep your wits about you and apply general separation-of-concern and testability principles. Use good software craftsmanship. If you do that, you can get what you want with QML. You can keep business logic out of the QML.
@KH-219Design Great reply. Yes, I think it can be done too, but it will take much more time, will be limited (no possibility to use templates etc), decreased performance, bulky build process and so on..
Again, I am not against QML at all, it has its use. I just want to express that me and I believe I am not the only one, would prefer a C++ only alternative.
Cheers
-
@Sandon I honestly don't think you have a good enough understanding of QML to make some of the statements you are making. For example, you mentioned trying using ".ui" files. That is not something you need to do to use QML.
When you write with Qt Widgets, you have to have somewhere in your code creating and hooking up your widget objects. You can streamline this behind factories and so on, but you are still doing it. When I was involved in writing a Qt Widgets app that needed many complex forms with dynamic content, we even went as far defining our own declarative system for constructing and arranging the widgets. My point is that you either have to write lots of explicit long hand code to create and set up widgets, or you have to implement your own bespoke systems to make it less painful and reduce boilerplate. QML essentially does that for you - behind the scenes, the QML file is driving the construction of a tree of
QQuickItems - allowing you to get on with the C++ code that really matters. -
@Sandon I honestly don't think you have a good enough understanding of QML to make some of the statements you are making. For example, you mentioned trying using ".ui" files. That is not something you need to do to use QML.
When you write with Qt Widgets, you have to have somewhere in your code creating and hooking up your widget objects. You can streamline this behind factories and so on, but you are still doing it. When I was involved in writing a Qt Widgets app that needed many complex forms with dynamic content, we even went as far defining our own declarative system for constructing and arranging the widgets. My point is that you either have to write lots of explicit long hand code to create and set up widgets, or you have to implement your own bespoke systems to make it less painful and reduce boilerplate. QML essentially does that for you - behind the scenes, the QML file is driving the construction of a tree of
QQuickItems - allowing you to get on with the C++ code that really matters.@Bob64
I confirm that my understand of QML is not good enough, but I can tell you I have been using Qt since Qt4, for more than 10 years.I know what .ui files are. I just mentioned them in the context of QML to make an analogy, but unfortunately it seems that my point did not get across well. Again, I just mentioned them, to give you an example of what I did not like: creating widgets.
I understand your point, and yes, there are also advantages. Like you, I created something like what you are describing for QWidget and it is an approach that works.
This story of keeping C++ to what is really needed is a story I have heard many times, especially for other languages.
Do you really think that there are no advantages in having a pure (let's ignore qmoc) C++ solution for your application/libraries?
-
@Bob64
I confirm that my understand of QML is not good enough, but I can tell you I have been using Qt since Qt4, for more than 10 years.I know what .ui files are. I just mentioned them in the context of QML to make an analogy, but unfortunately it seems that my point did not get across well. Again, I just mentioned them, to give you an example of what I did not like: creating widgets.
I understand your point, and yes, there are also advantages. Like you, I created something like what you are describing for QWidget and it is an approach that works.
This story of keeping C++ to what is really needed is a story I have heard many times, especially for other languages.
Do you really think that there are no advantages in having a pure (let's ignore qmoc) C++ solution for your application/libraries?
@Sandon said in Is it possible to use Qt Quick modules without QML?:
Do you really think that there are no advantages in having a pure (let's ignore qmoc) C++ solution for your application/libraries?
Honestly, I don't know. Pure C and C++ was a popular way to write GUIs in the 80s and 90s but, these days, there aren't a huge number of options to purely use C++. This maybe suggests that there are better ways of doing things. You haven't really explained what advantages you see.
On the other hand I do see definite advantages in an enforced separation of concerns and a declarative approach to defining a GUI. As I said, even when writing with Qt Widgets we quickly came to the conclusion that our own declarative approach was better than trying to code purely in C++.
There are approaches you can take, such as that outlined by KH-219Design, that eliminate essentially all Javascript. And Qt themselves are moving in a direction to support this in Qt6. See https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html. A design approach such as advocated by KH-219Design together with your QML compiled to C++ using the new QtQuick compiler sounds to me like it brings you pretty close to what you want, while retaining the advantages of a declarative approach to the purely UI layer.
I can tell you I have been using Qt since Qt4, for more than 10 years
The Qt Widgets project I referred to above to was begun over 20 years ago, originally using Qt2, and is still going strong! Though, I will be honest that I have not been using Qt continuously for that period - I had a fairly long break before returning to Qt in the last few years.
-
I've interviewed for about +30 development positions using Qt over the last 7 years. The developers are very uncomfortable with QML and it is management pushing QML at almost all the companies. The elephant in the room is that Qt is selling QML to management to compete with HTML5 / electron. There are more, thus cheaper, javascript developers than c++ developers and javascript developers can understand QML. QML helps the Qt company increase it's market share against HTML5. Before Lars Knoll left Qt, I asked him at a QnA about the topic of this post. He said quick widget substantiation from c++ was planned for sometime in Qt6. More recent inquires tell a less positive future for quick widget substantiation from c++.
-
I've interviewed for about +30 development positions using Qt over the last 7 years. The developers are very uncomfortable with QML and it is management pushing QML at almost all the companies. The elephant in the room is that Qt is selling QML to management to compete with HTML5 / electron. There are more, thus cheaper, javascript developers than c++ developers and javascript developers can understand QML. QML helps the Qt company increase it's market share against HTML5. Before Lars Knoll left Qt, I asked him at a QnA about the topic of this post. He said quick widget substantiation from c++ was planned for sometime in Qt6. More recent inquires tell a less positive future for quick widget substantiation from c++.
