Question on methodology: new project ahead, how to approach?

[gardiol]

Hi all!

i need some advice from more expers users. I am migrating a project forward, and i want to find out what is the best approach, to start in the right direction.

Most of the functionalities are implemented in a C/C++ "core" which is compiled as a library (it's in development, and i have access to full source code).

This "core" requires an user interface, this UI can be roughly divided into two areas:
1) some custom controls where the "core" will provide already drawn bitmaps
2) some more general pages to edit and modify data. The data is provided by the "core" but the presentation shall be done in the UI layer

My Qt experience is with widgets.

This is how i know how to proceed:
- implement custom widgets for the custom controls
- implement all the rest with layouts and widgets

Clearly, i would like to move forward and use QML as much as possibile because the goal is to support mainly mobile targets. Keep in mind i _MUST_ support Symbian and MeeGo. Android and iPhone will get their own native port, i guess, but i cannot tell at the moment and maybe Qt could provide a quicker "first approach" to them too.

How should i proceed?

Some toughts i had so far:
1) Create custom widgets and integrate them on a QML design (not sure it can be one with QtQuick 2.0? not a target at the moment, but why go an obsolete way?)
2) Implement the custom controls with QDeclarativeItem... but i cannot find out how to intercept events (like onResize!)... and i need that...
3) ??? write here and ask for ideas

Any suggestions are welcome. I want to start on the right foot!

[wysota]

First things first... Targetting both Android and Symbian will be hard as Qt4 is not available for Android and Qt5 is not available for Symbian. Thus if you really do need both, you have to implement your system in such a way which is buildable with both Qt4 and Qt5. This is easier done with widgets than with QtQuick unless you use the obsolete QtQuick1 with Qt5.

Having said that, I can suggest to focus on developing the "core" right now which should be completely UI agnostic. This way you can postpone the decision on the UI or even you can have a prototype UI based on widgets and then quickly switch to QtQuick if needed. If you need custom drawing, base it around a render function that works on a QPainter pointer -- then you can use your drawing "engines" with both widgets and QtQuick.

Try to design your system in such a way that it doesn't care if it is presented using widgets or not.

[gardiol]

Thanks for the quick response!

the core is being developed in an absolutely agnostic way indeed. That's the key point, since WindowsPhone is also on the list

So basically your suggestion is go with wigets because QML is still not mature enough to be a safe bet for the future?

I can go with widgets! I have quite a lot of experience with them... but starting from scratches, i tought investing some time learning something new would be a better approach? Indeed, i prefer to spend time on cross-platform things than an obsolete QtQuick 1.0...

[wysota]

So basically your suggestion is go with wigets because QML is still not mature enough to be a safe bet for the future?

No, I didn't say that. What I meant was that if you want to target both Qt4 and Qt5 (aka Android and Symbian), it will be easier for you to implement a stub of UI (if you need it for developing your "core") in C++ and widgets (which is an area familiar to you) instead of QML/QtQuick which requires you to do some additional learning.

but starting from scratches, i tought investing some time learning something new would be a better approach?

As I said, I'd suggest to implement the core first. Then you can spend as much time as you want for learning QML.

Indeed, i prefer to spend time on cross-platform things than an obsolete QtQuick 1.0...

The problem is QtQuick 2 requires OpenGL/ES 2.0+ support and is not implemented for Symbian. Thus you're stuck with both QtQuick 1 and QtQuick 2 if you want to target old and new platforms. Widgets on Android will probably look terrible too, so eventually you'll be forced to port your UI to QtQuick if you want the application to blend with the rest of the system.

[gardiol]

Well, now it's clear.

I will keep on QWidgets then, for the time being. It's the second time i pass on QML tough. It's not that i am not trying. The first time it was just out and after some thinkering i decided that widgets where more stable and better supported (Qt 4.7 was not out yet). I developed the version 2.0 of my application using widgets.

Then, after deciding to refactor the application for a wider cross-platform support, i tought this was the time to go QML...

It seems it's not the case, again, because of this QtQuick 1.0/2.0 incompatibility...

I would love to go Qt5, but since my main platforms are unsupported... well... i can't.
I would keep on QtQuick 1.0, but since it's deprecated for Qt5... it's not worth to study

Can't believe widgets are still the best option. But thanks for letting me save time!

Anyway, Android will have it's Java native UI i need Qt only as UI for Symbian and MeeGo (and desktop). So i should not bother with QtQuick 2.0 and 1.0 is just a waste of time nowdays.


thanks!

[wysota]

You shouldn't pass on QML. Just don't start your project by learning QML, postpone it until later and in the meantime either don't use a GUI at all or mockup one using widgets.

It seems it's not the case, again, because of this QtQuick 1.0/2.0 incompatibility...

I would love to go Qt5, but since my main platforms are unsupported... well... i can't.

The only unsupported platform is Symbian.

I would keep on QtQuick 1.0, but since it's deprecated for Qt5... it's not worth to study

QtQuick 1 and 2 are 90% compatible, spending time on QtQuick 1 will not be wasted if you decide to switch to QtQuick 2 some day.

Anyway, Android will have it's Java native UI

So, you want to mix C++ "core" and Java UI? Good luck

i need Qt only as UI for Symbian and MeeGo (and desktop).

Qt5 is available for MeeGo. It's not in the default repositories but it is available.

So i should not bother with QtQuick 2.0 and 1.0 is just a waste of time nowdays.

I wouldn't agree.

[gardiol]

I will not pass on QML, just for now.

What is the point in QML if i only need to target Symbian and MeeGo?

A simple mockup widget gui will do, also on desktop, for the time being. Before wasting long time on widgets, i will check again what are the best options anyway! I don't want to do hard work on QtQuick 1.0 just to throw it away! Anyway, QtQuick 1.0 is so much different from 2.0? Rewriting from 1.0 to 2.0 would it be hard or long?

[wysota]

I edited my previous post in the meantime, most of your doubts are answered there.

[gardiol]

Thanks!
ok, so now i am more confused than before...

Well, i guess QtQuick 2 is not a "superset" of QtQuick 1, so if i use QtQuick 1 it's going to work magicly on QtQuick 2 platforms... right? It's more like the Qt3 -> Qt4 migration, where "it worked, but soon had to be fixed" (maybe without the Qt3Support compatibility layer, in this case).

Ok, i will quickly fix a working stubb UI with widgets, just to get the core going, besides automated tests which do not need any UI. It should take very little time (like half day). Later on i will try to figure out how to implement some more complete UI prototypes using QtQuick 1 and do some real world testing on Symbian/MeeGo.

The widget stubb should work also for initial android integration, i guess.

Then a decision will have to be made: develop a QtQuick 2.0 port alongside the 1.0 or go Java UI. I agree, it's not easy or nice, but if properly planned even JNI can be smoothed out a bit...

To be honest, at the moment i have a port of the older release on Android using Necessitas. Ministro is a pain (99% of my android users complained about ministro and downloading Qt libs, they either do not understand what is going on OR plainly believe it's a malaware trying to take over the phone. And they are focused users who got the "beta" android release directly from my own private email! i shudder at releasing something like that on Google Play! it would be KILLED by bad reviews without even having started the application). So i would prefer going with embedded libs, but this means a huge download, and more drawbacks.

I don't know, yet, what is best. A native UI with a plain C++ core would be better for the users... worse for me of course.

[wysota]

Well, i guess QtQuick 2 is not a "superset" of QtQuick 1, so if i use QtQuick 1 it's going to work magicly on QtQuick 2 platforms... right?

If you change the import statements then 90% of things are going to work.

Then a decision will have to be made: develop a QtQuick 2.0 port alongside the 1.0 or go Java UI. I agree, it's not easy or nice, but if properly planned even JNI can be smoothed out a bit...

I think that if you have the full power of Qt to develop your "core" and then you constrain yourself (in your own free will) to give up all that power in favour of using Java UI then that's not a good project decision.

[gardiol]

Thanks for all the good info!

At the moment, i will keep working on the "core", that's where most of the effort will go anyway. the "presentation" layer must be independent and i will choose the best options when i get to it. In this way, also, the core will be much more independent too.

Anyway, i believe the path is still not clear.

Widgets are not good for mobile, not supported and not working properly.
QtQuick is fragmented (1.0 Symbian, 2.0 future, 90% easy to port, but i would still need to maintain two ports)

Probably i will make a Qtquick 1.0 UI for Symbian, then see if it's worthwhile to upgrade to 2.0 for Android or choose a Qt-less solution. This will depend on the state of Qt integration with Android in the next 6 months.

[wysota]

You have to be aware Symbian is more and more obsolete every day and hardware it is used on is not strong enough to support QtQuick 2. If you don't need QtQuick 2 features, you can still use QtQuick 1 with Qt5 -- it is deprecated but it is not going to vanish.

[gardiol]

I know Symbian is pratically obsolete. Still, what is the way forward?

I want to keep supporting Qt in all the means i can... so one QML UI will be developed... maybe Symbian will be ventually dropped... and maybe at the same time AndroidQt support will be good enough for my application...

We will see!

Again, thanks for all the support, at least i know it's too soon so head into QML until i have my "core" ready and a clearer way forward.

ps: Symbian might be obsoleted, but still my Nokia 5800XM gives me almost 12 hours of continous GPS tracking with one stock battery! My Galaxy SII with 2Ah battery does not reach 6 hours, so it's useless for my application target!