[Development] Suggestion on QML portability

[Alan Alpert]

On Mon, 16 Jul 2012 03:18:02 ext André Pönitz wrote:
> On Mon, Jul 16, 2012 at 10:02:33AM +1000, Alan Alpert wrote:
> > The theory is that you're not trying to maintain a single
> > codebase for both QML1 and QML2.
> 
> [Maybe it's about time to run reality checks on certain
> theories anyway...]

It's a major version change, what did you expect? It's a pain to maintain even 
a QWidget application for a single Qt 4 and Qt 5 code-base, all the assistance 
I'm aware of is for porting Qt4 -> Qt5 in one go.

Note that nothing was taken away in QtQuick 1.1, where such aggressive 
deprecation would not have been appropriate for a minor revision.

> 
> > > [...] Is there really that much pain in having a
> > > deprecated closeSoftwareInputPanel method so I don't have
> > > to resort to somehow preprocessing the QML, for instance?
> > 
> > Yes, there is that much pain.
> 
> Pain for whom? The makers of Qt or the users of Qt?
> 
> The idea of re-using chunks of code in different products,
> possibly targeting different environments is not exactly
> unheard of.
> 
> At some point of time there was some kind of consensus that
> _using_ Qt should be painless, even if that causes a bit of pain
> on the implementation side. I'd like to get back to that state.

Even better would be to have it be painless on both sides. [1]
 
> > At least that's my interpretation from the example of Qt3Support.
> 
> Qt3Support provided a few step stones when porting from Qt 3 to
> Qt 4 and as such was highly appreciated in the Real World. This
> e.g. allowed normal feature development and maintenance being
> interleaved with porting the GUI.

QML has a different model for allowing normal feature development and 
maintenance to be interleaved with porting the GUI, perhaps it hasn't been 
explained well enough.

The QML model is that you aren't forced to port the GUI immediately for a 
different Qt, giving us Qt3Support like functionality for free. If you don't 
want to port parts of the UI to QtQuick 2 you continue to import QtQuick 1, 
which is also shipped with Qt5. It's just like when Qt 4 provided the Qt 3 
widgets, except that you don't have to make *any* changes to your QML code 
(and that QtQuick 1 and QtQuick 2 items can't coexist in the same view, making 
it harder to split up your GUI porting in some designs). Hopefully the QtQuick 
1 module will be dropped in a 5.x timeframe, but if people still use it widely 
I can see it lasting as long as Qt3Support did - when was Qt3Support 
originally planned to go away ;) ?

This model should make application development less painful for developers, 
not more. Qt developers (and developers of QML modules like the MeeGo 
components) do have more versions to support though, a bit of pain that I 
would like to see go down - if there are ideas beyond shifting the pain around 
between modules.

The other uncertainty is that darn "real world" that I know so little about. 
>From my position inside an ivory tower, on a far-away and magical tropical 
island, I don't see any evidence of QtQuick 1 use in the real world ;) . I 
would be interested in statistics on QtQuick 1 proliferation if anyone has 
them.

--
Alan Alpert

[1] Because it's mis-quoted so often yet actually relevant here, I'd like to 
reference Cicero's 'De finibus bonorum et malorum' in support of this point: 
"...neque porro quisquam est, qui dolorem ipsum, quia dolor sit amet, 
consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt, 
ut labore et dolore magnam aliquam quaerat voluptatem."