I'm sticking with Widgets
-
The QML designer is buggy, and QML itself is another layer of abstraction. The Widget designer, however is much more stable and produces code which ends up being part of the compilation process.
-
That's fine. Both QML and Widgets are and will continue to be fully supported.
In Qt 6 large parts of QML will be compiled into C++, too.
-
Not that I have used QML, but I don't really understand what it is for?! If you have a large program with loads & loads of windows/dialogs and it has to do a fair amount of stuff, all I see is questions about how to accomplish from QML for which the solution is to write C++ code which accesses the underlying widget methods. So what's the point, other than for small UIs?
-
@JonB I can tell you the reasons, why I went into QML.
Performance.
The native GPU rendering makes it the solution for mobile devices. Especially as it is that much faster and easier to create and populate a scene than using QOpenGLWidget or something similar.
Animation.
It is so, SOOOOO easy to do any kind of animation in QML where as with QWidget you'll have to sacrifice your first born and most of the time it's not enough. -
@JonB said in I'm sticking with Widgets:
Not that I have used QML, but I don't really understand what it is for?! If you have a large program with loads & loads of windows/dialogs and it has to do a fair amount of stuff, all I see is questions about how to accomplish from QML for which the solution is to write C++ code which accesses the underlying widget methods. So what's the point, other than for small UIs?
What's the point of QML? Oh there are many. It works great also for big UIs, don't worry.
The biggest advantage is just how easy it is to create beautiful, animated, touch-oriented UIs. Then there is also stronger separation of logic and UI code (in widgets it's much easier to mix these two). Also, with QML, designers can create the UI while programmers focus on logic (I have not tried that approach, though). It's easier to create custom components that with widgets. In some cases it's easier to get good performance, too (since part of the drawing work is done by GPU). And of course, it is much easier to get a solution that works great on desktops and mobile phones with the same code. Widgets on mobiles - while they work - are not a pleasant experience.
-
Thank you. You both mention mobiles, which is interesting. I could care less about mobiles, they are from the devil anyway :) I take the point about animation. I am no-animation, desktop-only, so that may explain.
Nonetheless, I do see from questions here that often a behaviour wanted from QML requires dropping into C++ Qt code to achieve the desired. That's fine, it just means that in that case doing it all from QML does not prevent you having to learn about the Qt C++ side of things as well as QML.
-
@sierdzio Not that good for big UI develop for desktops from my experiences. Problems I found for qml are
-
The bigger the UI become, the more I cherish the compile time diagnosis of the c++ offer(it is more than type safe), it is a mess to keep those strings of qml or the bridges of qml and c++ update correctly. When you need to write a bridges to make two worlds communicate together, you are adding more complexity to the projects already, unless the qml can do something QWidget/QGraphicsView cannot, but it is the opposite ways, when i need to develop complicated ui on desktop, I always found QWidget looks much more native, more components, more mature and easier to use compare with qml(users don't care about animation or fancy ui effect, really)
2: it is easier to control resources by pure c++. Why should I scratch my head to optimize 40000 chips on screen by qml when QGraphicsView solve this problem perfectly?
3 : Qt company still prefer QGraphicsView to develop the State Charts editor, if qml are so damn great, able to replace QWidget, QGraphicsView, they should use it to develop CAD tools like app.
4 : There are more developers of c++ rather than qml.
5 : You can find very details example to show you how to develop complicated, eve CAD like ui of QWidget but not qml.
6 : Qt company adopt the philosophy of "Features first, bug fix later", better stick with QWidget if youwant to reduce the "aha" moment, there are many bugs opened more than 2 years, they don't care.
7 : Don't expect Qt company listen to the voices of developers, they don't care about your voices but your money.
8 : Widget Designer is much better than qml Designer, stable, fast and easy to use. This boost up the speed of ui development, especially when the ui components are complicated, it is a good things if you do not need to change the ui by codes but just add, delete, move them around by widget Designer which just work, you can see most of the end results instantly.
I use qml for a desktop project and feel regret after a year, I miss QWidget more and more and begin to replace them back by QWidget and QGraphicsView.
The place I found them shine is on mobile(although there are many things of Qt are half done on mobile, we need something like Felgo), unless you need ui which works on mobile, or a mobile like ui which works on mobile and desktop(design for mobile first, else you will cry no matter you are using qml or QWidget), else qml is not better than QWidget and QGraphicsView.
-
-
@sierdzio said in I'm sticking with Widgets:
Then there is also stronger separation of logic and UI code (in widgets it's much easier to mix these two).
Don't think so, it totally depends on the skills of the developers.
@sierdzio said in I'm sticking with Widgets:
Also, with QML, designers can create the UI while programmers focus on logic (I have not tried that approach, though).
My experiences told me the opposite way, many users don't care about qml nor the qml designers, they found widget designer easier to use and more intuitive to customize the look and feel by css. Advertisement of Qt company are not that...solid.
Agree with you it is a better choice on mobile, or create ui suit for desktop + mobile, otherwise I don't find much benefits of qml.
I use python for machine learning, html and js for website, qml + js + c++ and platform specific language for mobiles, c++ for desktop apps with gui(no qml, no).
