Porting C++/Qt to C++/QML: to do or not to do?

[wspilot]

Hi,
I am seeking for input on porting C++/Qt to C++/QML. I have 60K+ lines of C++/Qt code that I want(ed) to port to C++/QML.
QML seems to be necessary for mobile devices.
Although the nice people on the forums being very helpful, after a week, I couldn't even get a simple C++/QML application to work, due to problems in the QML-C++ interfacing. Some examples:
Pagestack: cannot (re)size it; cannot push page; initialpage does not work. Toolbars not being loaded. (Some items I solved with work-arounds). No documentation on (conceptual) differences between things like Item, Page, Window, etc.

My basic question is: should one try to port large C++/Qt applications to C++/QML applications, or is QML not yet matured enough. I would like to hear from people that realy tried this excercise. I have read most the examples , documentation, watched the video's, but these are all very simple examples, not dealing with heavy GUI interactions.
Thanks.
r.

[leon.anavi]

[quote author="wspilot" date="1333449461"]
My basic question is: should one try to port large C++/Qt applications to C++/QML applications, or is QML not yet matured enough.
[/quote]

What will be the benefits to port your C++/Qt app to C++/QML?

In my opinion in general there is no point to waste time to rewrite working C++ source to QML unless you gain long-term benefits.

[wspilot]

"Mobile developers should use Qt Quick instead of C++ based UIs. Desktop app developers may still choose to use QWidget where appropriate" (http://www.developer.nokia.com/Community/Wiki/Category:Qt_C++_UI)
Also, the symbian Belle components are also only accessible via QML.
r.

[SteveKing]

I don't think QML is required for mobile devices, it's just that if you were starting from scratch it would make sense.

From my experience, our application was nearly complete when Qt 4.7.0 was released and we took the decision to port to QML. It took 2 SW engineers and UI designer 3 months to move ~10k lines of code + UI to QML. This included getting to grips with QML and some of the early bugs and also getting it working on our WinCE targets.

Was it worth it? Now we've gone through the pain I would say yes as the work we're doing now has been made much easier. Would we have done it if the application had been released/mature, I'm not sure.

[wspilot]

Thanks.
Clear answer. I am doing this in my spare time, with 60+k lines....
Taken into account that:
Nokia (read: Microsoft) is euthanasing Symbian and MeeGo (they don't even promote their excellent and best phone, the meego N9, at the cost of the WinPhones!), and
Qt/C++ stays the standard for tablets and desktops,
I'll just stick to Qt/C++.
By the time that QML becomes unavoidable, Symbian and Meego will probaly have died.
And, hoping that Android/Qt will grow mature in the meantime.
r.

[andre]

I think a lot of your statements and expectations from your last message are unfounded. If this is the thinking you apply when you need to decide if you want to port from using widgets to QML for your GUI or not (again, it is not Qt/C++ vs C++/QML or something like that), then I wish you all the best. I would research my assumptions a bit better before committing to a choice like this...

[wspilot]

Every developer/company has to make choices on platforms, SDKs, etc. If you are lucky, you do this only at the beginning of your project. Unfortunately, I had to reconsider my options at the end of the development cycle (my application is in beta), and for sure, I am not the only one.
Why did I had to reconsider?
Because I was silly enough to believe in the upcoming MeeGo platform. My target hardware was mainly tablets. So, yes you are completely right: I should have reseached my assumptions a bit better before coming to my choice. My big mistake was that I trusted Nokia ("MeeGo the new platform for mobile devices and tablets!").
So, now where to go with my Qt application for the MeeGo tablets? Oh well, at least I can try to 'down grade' to mobile phones: Qt supports Symbian and MeeGo phones.
Still, in order to use the specific Symbian/MeeGo components I need to switch to QML. I did some testing to make an assessment of the work involved. Asked some advice and got an answer (see above).
So, redesign is needed. That implies quite some coding. So now I am at a point to make choices again. It is not just a technical question, but all options need to be considered again (risc assessment).
If my target harware would have been non-Nokia (mostly low risc), I would certainly look a bit more into QML. But that is not the case and this time I'll walk the save side.
Don't get me wrong: I really like Qt, even QML, but I also want a my application to be able to run on some device/OS somewhere in time. Maybe Nokia shareholders will take action and put Nokia on track again (and create a future for Symbian and MeeGo again), but I cannot gamble on it. There is to much work involved.

[wspilot]

Additional note:
there might be hope: http://www.linkedin.com/company/jolla

[AlterX]

I think you should consider to port an app only if you want change the UI of the app; QML permits to do a lot with graphics and animations.

[wspilot]

[quote author="AlterX" date="1342787435"]I think you should consider to port an app only if you want change the UI of the app; QML permits to do a lot with graphics and animations.[/quote]

All the serious graphics is openGL, and a lot of (static) GUI.
The latter would certainly be nicer with QML.

Since Nokia is out and Digia and Sailfish in, I am certainly gonna have a serious look at it again.

[feldifux]

I can repeat my opinion about this discussion, which had a similar topic here: http://qt-project.org/forums/viewthread/21846/#104453

If you should choose QML or C++ really depends on the kind of application you are creating:

• Should it be targeted for mobile, desktop, or both?

• Mobile only: definetely go for QML for the GUI, application logic does not matter which you choose
• Mobile & Desktop: use the same application logic either in C++ or QML, and design 2 different UIs for desktop and mobile. For mobile QML is preferrable, for desktop QWidgets
• Desktop only: at the moment QtQuick components for desktop are not finished, but you can have a look at them and decide based on your requirements if they are mature enough, otherwise go for QWidgets

• Custom GUI or native-looking?
  This is essential! If you want to design your own GUI (i.e. custom buttons, sliders, etc.) QML is preferrable. For native-looking applications on desktop, see the Desktop only point above.

• Static or dynamic GUI?
  One of the main advantages of QML is the super-fast way to create fluid, animated GUIs. If you do not need that, QWidgets might be sufficient.

As you can see, these points are all UI-specific decisisions. I do not know how much of your C++ code is actually GUI-code, and how much is application logic. I would keep the application code in C++ as it is probably not worth porting it, and you can still make it available very easily to QML as own QML items or context properties.

For new code, I would start with QML first as you are much more productive as it is so much faster to write. And only code the performance-critical parts in C++ if you find out it is too slow with QML.

[wspilot]

Thanks.
Device targets: tablets and mobile phones.
For now I am going for Sailfish (hope we'll see some components soon..). So, that calls for a QML GUI.
There is lot of non-GUI C++ code (navigation, calculations, binairy preps for OpenGL, etc.).
But also event handling and GUI objects manupilation. This will have to be done via interfacing the C++ code with QML. I am setting up a test app to see how/if it would work.

Currently the "application":https://sourceforge.net/projects/pilotnavigator/ (aircraft navigation) has a QWidgets GUI running on a netbook.