[Interest] To QML or not to QML...

Jason H scorp1us at yahoo.com
Tue Mar 6 20:01:09 CET 2012


My own experiments in QML have leave me to believe that aside from it's limitations (there are many) that most everything "visual" and not classically widget-oriented is made substantially easier.
If it's 'hard" in QML you're probably doing it wrong, unless it's a QML limitation.




----- Original Message -----
From: BRM <bm_witness at yahoo.com>
To: Interests Qt <interest at qt-project.org>
Cc: 
Sent: Tuesday, March 6, 2012 12:26 PM
Subject: Re: [Interest] To QML or not to QML...

> From: Preet <prismatic.project at gmail.com>

>On Mon, Mar 5, 2012 at 12:54 PM, Jason H <scorp1us at yahoo.com> wrote:
>> It is my understanding that the major differences between 4 and 5 are that 5
>> assumes (and requires) a hardware GL implementation (scenegraph), where 4
>> does not.
>
>I was under the impression that the legacy QtQuick 1 stuff would be
>available in Qt5 as is with software rasterization under the existing
>'QDeclarative' classes/module. The QtQuick 2 stuff all seems to be
>under the 'QQuick' module.


Yes, there's a bunch of renaming going on, and such from what I can tell on the development list;
but I haven't paid too much attention to the QML side of things.


>>In terms of your coding, his largely comes down to the import
>> statements that are used.
>> From: BRM <bm_witness at yahoo.com>
>> To: Interests Qt <interest at qt-project.org>
>> Sent: Monday, March 5, 2012 12:39 PM
>> Subject: [Interest] To QML or not to QML...
>>
>> I'm working on an application that presently uses Qt 4.7 for a front-end to
>> a larger system. One of its main tasks is to display data in the system
>> which requires rendering up to around a thousand or so points and overlaying
>> a template of the ideal against the actual. Presently it does all the work
>> in a custom QWidget class and implements the drawing in
>> QWidget::paintEvent(QPaintEvent *event). However, I am getting ready to do a
>> major rewrite of this functionality - namely I want to add some text labels,
>> values, and lines for some of the measurements related to it, and am trying
>> to determine the best possible path of two that are available.
>>
>> No matter what I do, there will be some major rework to my application as
>> things are just changing a lot to do the new functionality I am seeking
>> (can't be helped).
>>
>> The below are the options I am aware of:
>>
>>
>> 1. Rework the painting to be done to a QImage/QPixMap/etc, and then use
>> QGraphScene to display the data, do the overlays, etc.
>> 2. Use QML (Qt Quick 1) similar to #1
>> 3. Use QML (Qt Quick 1) similar to present operation
>>
>> My main requirements are that I need to be able to update at least a few
>> times a second (typically 3-5 times a second; possibly higher), and adding
>> the new text with lines and numbers for the measurements.
>>
>>
>> As I have not yet touched QML, and there are many on this list who have,
>> what you recommend?
>> Would it be worth trying to do this in QML - either #2 or #3 - or should I
>> just stick to #1?
>>
>> For those involved with Qt5, will there likely be big changes in the
>> functionality in moving this to Qt5 when the time comes? I understand (from
>> the development list) that QML1 is generally easy to port to QML2 but that
>> it depends on what you do with QML; am I likely to run into a big issue in
>> the port given what I need to do?
>
>It's not clear why you want to move to QML... is it because you want
>to draw stuff (text and other graph elements) in QML directly (and
>think this might be easier)? If your current app is setup using
>'form-style' widgets  and has a traditional desktop GUI, then it might
>be a lot of additional effort to move it to QML.
>
>There's this QML canvas project:
>http://qt.gitorious.org/qt-labs/qmlcanvas, that might make it easier
>for you to draw your graph. But really this depends on the complexity
>of what you're trying to do. There are also projects like Qwt:
>http://qwt.sourceforge.net/, which use widget-based Qt to draw
>complicated graphs.


My main reason for thinking about whether or not to use QML is two fold:

1. I am about to embark on something that no matter what I do is going to be complicated.
Perhaps QML can make it simpler; I don't know.

2. (The bigger reason) Qt is moving towards QML. Since #1 has to be done any way, if QML will
meet the need, why not move to it now instead of later?


> From: Sivan Greenberg <sivan at omniqueue.com>
>To: BRM <bm_witness at yahoo.com> 
>Cc: Interests Qt <interest at qt-project.org> 
>Sent: Tuesday, March 6, 2012 6:21 AM
>Subject: Re: [Interest] To QML or not to QML...
> 
>Hello!
>
>On Mon, Mar 5, 2012 at 7:39 PM, BRM <bm_witness at yahoo.com> wrote:
>>
>> As I have not yet touched QML, and there are many on this list who have, what you recommend?
>> Would it be worth trying to do this in QML - either #2 or #3 - or should I just stick to #1?
>>
>
>You could try and use pure QML (e.g. have QML elements of a Point and
>rest of your entities) abstraction and do a test run if speed is
>what's important in populating thousands of items.
>
>I would guess that drawing inside a QML View will behave and have the
>same constraints as drawing inside a QWidget, perhaps with some
>performance difference depending on the complexity of your drawing if
>you stick to high level item (complex shapes as custom elements
>themselves) but if you implement it yourself you might need to
>re-implement a translation layer from highlevel -> geomtric shapes ->
>back to low level drawing and and profiling and perfecting your QML
>should prove much more beneficial.
>
>QML abstraction will give you the enormous (in my experience) benefit
>of close to effortless reusable components, and making the "drawing"
>process close to 'code-free' , real nicety when you add more overlays
>and detail perhaps in the future, or base more advanced display items
>on what you already have, or use this overlaying and layers in many
>other apps you might want to develop further (again, in *my*
>experience, with less hassle than using QWidget code) , and be able to
>use QML's cool fluidity and relatively easy to achieve display and
>device scaling and fit, and.. and... (well you got it, I love QML ;).
>
>Eventually, I've seen people here make their QML become very
>performant  with the suitable know how and I'm sure you could find
>help if you run into issues. The important thing is to try and
>experiment with your data set before you invest into switching
>technologies, a good approach to follow before any major rewrite!


Thanks for the insights; that's right along what I was looking for.

I started reviewing more of the APIs for QML (under 4.7) and QGraphicsScene,
and may have found a middle-of-the-road approach.

That is, build it out the widget set using the C++ side of QML.
I think that will allow me to go ahead and do it as if I were doing #1 to start with,
and then enable a smooth transition to QML as well.

However, instead of drawing to a QImage/etc, just doing it directly as in QML (QGraphicsSceneItem, I think).

I've got a couple weeks to think this over and experiment before I commit to any one path.

But QML is certainly looking interesting for this work.

Thanks!

Ben

_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest




More information about the Interest mailing list