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_witn...@yahoo.com> To: Interests Qt <interest@qt-project.org> Cc: Sent: Tuesday, March 6, 2012 12:26 PM Subject: Re: [Interest] To QML or not to QML... > From: Preet <prismatic.proj...@gmail.com> >On Mon, Mar 5, 2012 at 12:54 PM, Jason H <scorp...@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_witn...@yahoo.com> >> To: Interests Qt <interest@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 <si...@omniqueue.com> >To: BRM <bm_witn...@yahoo.com> >Cc: Interests Qt <interest@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_witn...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest