QML vs QGraphicsView and friends
-
As far as I know QML is built atop of the QGraphicsView framework. So what are the benefits of using QML against using QGraphicsView directly. I'm looking for something that will give me the push I need to finally get to know QML, because for now I still feel that anything that can be done using QML can also be achieved using QGraphicsView directly (granted with more code but I actually like C++ so …).
-
This is not a question about how you like C++: the fact is that using QML and QT-Quick to develop the User Interface you can work with a descriptive language and separate the interface from logic. This is the best way to develop for mobile platforms, if you think that interface is subject to changes while logic can maintain totally intact its robustness working in a compiled - and in someway "protected" - environment independent by the user experience.
Last, but not less important, the features and capabilities of QML for create impressive layouts and High quality grpahics. -
bq. QT-Quick
Please
Qt != QT so its QtQuick not QTQuickbq. separate the interface from logic
bq. Last, but not less important, the features and capabilities of QML for create impressive layouts and High quality grpahics.
And You think this is not the case with QGraphicsView why?
Don't get me wrong I know that its easier to do this with QML, but as with everything that operates at a higher level you do get performance penalties. -
As a linux-embedded developer, I have so clear what you means. Higher level penalizes ALWAYS performances.
The thing that I appreciate is that with QML a part of the application can be external from the C++ complexity and is a language with interpreted sources. This mix can be a great potential is you think that your C++ can manipulate and change the QML sources after the application is installed on the device.I imagine that you can replicate that there is also a Qt-script,but I had not yet had time to consider in-depth this options.
(don't get me wrong if sometimes I write QT... I hate Q(uick)T(ime) :) )
-
That performance penalty may nor may not apply. You might be able to use optimizations in QML written by an engineer better/smarter than you (as in you in general, not personal) and that would be possible to write by hand in C++, but may never actually get written. Also, while QML is currently build on the GraphicsView framework, it is perfectly possible to make it work on a different graphical backend. In fact, that is the goal of the QML-scenegraph project. You will not be able to get the kind of speedups you get then with GraphicsView or anywhere else in the QWidget world.
The main benefit of using QML is that you are able to get to a result quicker and write less interaction and state management code, while at the same time being able to easily work closely with a designer on the UI. The time you save there, can be spend optimizing the real performance issues in your application. I am not claiming QML is perfect; in fact I think it still needs a lot of work to be usable for building real applications, but it does show real promise. I just hope it will stay around a bit longer as some other technologies we have seen introduced in Qt over the last couple years...
-
Andre, I totally agree with you.
I think that it sound little "partisan" that C++ is best. For my experience, the best solutions are always integration solutions, where the right language (or more complex language-based platform) is used, depending by the context.
As a matter of fact, an in-depth analysis demonstrate that both QML and C++ (like java and/or Python where needed) are both on the same "development" level, not high level and low-level language.
-
I don't know all the technical details but what I understand is that making fast QML as a developer is quite easy because the authors of QML have made the best possible solution for the use-case. Making fast QGrahicsView might not be that easy, you have to learn quite a bit about the graphics view system.
With QML, the trolls can accomplish things like QML scenegraph (http://labs.qt.nokia.com/2010/12/02/velvet-and-the-qml-scene-graph/) which I'm looking forward to.
-
[quote author="Andre" date="1299750263"]That performance penalty may nor may not apply. You might be able to use optimizations in QML written by an engineer better/smarter than you (as in you in general, not personal) and that would be possible to write by hand in C++, but may never actually get written. Also, while QML is currently build on the GraphicsView framework, it is perfectly possible to make it work on a different graphical backend. In fact, that is the goal of the QML-scenegraph project. You will not be able to get the kind of speedups you get then with GraphicsView or anywhere else in the QWidget world.
The main benefit of using QML is that you are able to get to a result quicker and write less interaction and state management code, while at the same time being able to easily work closely with a designer on the UI. The time you save there, can be spend optimizing the real performance issues in your application. I am not claiming QML is perfect; in fact I think it still needs a lot of work to be usable for building real applications, but it does show real promise. I just hope it will stay around a bit longer as some other technologies we have seen introduced in Qt over the last couple years...[/quote]
Thanks Andre that’s what I wanted to hear. I was not aware of that QGraphicsView would not benefit from scenegraph. Getting a significant speed-up combined with the ease of QtQuick is a truly grate prospect.
bq. I think that it sound little “partisan” that C++ is best.
I never stated that C++ is a the best solution to every problem. I just wanted to know what were the benefits of QML over direct QGraphicsView usage.
I also wonder if there are any QtQuick books in the pipeline as I have always enjoy good reading material and am currently enjoying "Advanced Qt Programming" by Mark Summerfield.
-
kkrzewniak,
me, as technical book writer, can tell you that what you can find on the net and on these forums is incomparable for helping, understanding and teaching to you. Too much times I started writing the editor commitment, then when the book is finished the best thing to do is that I rewrite the book ;)
-
This might be the case with some books but I really prefer reading nicely published books to reading from the screen. And some thing cant be found on the net (non Qt related topics) and next to the documentation good books are the best learning source.
-
I can suggest an e-ink based reader, then I can share my waste bibliography...
Sure!
