[Development] Suggestion on QML portability

[Alan Alpert]

On Mon, 16 Jul 2012 21:19:41 ext André Pönitz wrote:
> I am afraid I am in "Can't resist" mode today...

I'm afraid that plight is communicable over email...

> On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote:
> > [...]
> 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, [...]
> 
> This is incidentally one of those theories in need of a reality
> check I was refering to.
> 
> The assumption is wrong, as proven by the example of Qt Creator.
> 
> After some initial effort to make it compile with Qt 5 at all
> (mostly due to the modularization and the Gui/Widget schism) it
> compiles rather nicely with Qt 4 and Qt 5 from a single code base
> without much #ifdef hackery.

Yes, sorry. As you and Oliver have pointed out, Qt C++ applications do not 
have this problem. I blame my confusion on not re-compiling my creator since 
when one had to run the fix headers script every time (which seems to mean... 
last year).

This does mean that QtQuick 2 is not as compatible with QtQuick 1 as Qt 5 is 
with Qt 4. It is unfortunate, but QtQuick is not bound by the same 
restrictions; this is why it's QtQuick 2.0 and not QtQuick 5.0. If anyone finds 
that porting QtQuick 1 applications from Qt 4 to Qt 5 (while still using 
QtQuick 1) is more difficult than QWidget applications speak up now, that would 
need to be addressed. Thanks to Thiago for pointing out already one part that 
is slightly worse.

> > [...]
> > 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.
> 
> It's not so much the model that needs to be explained, but the
> reasoning behind it.
> 
> What's so wrong with the "preprocessor" model[1] of "compatibility"
> that a new model had to be invented, implemented, debugged,
> usability-checked, documented, communicated to the user?
>
> [1] I am not necessarily refering to the exact #include, #if etc
> syntax, but the concept of "easy-to-use 'compile' time conditionals"

Because QML is an interpreted language and effectively has no compile time. 
What you're thinking of as compile time, when you build your C++ code, doesn't 
have to do anything to QML. It can, but that would be something for external 
tools, not built into the interpreted language runtime (because it hasn't been 
started yet). There could be a tool like qmlmin which reprocesses QML files at 
the build stage to apply C style preprocessing, although then the source files 
wouldn't be "valid" QML.

If you like the idea in the interim, a quick play showed me that 
gcc -x c -E test.qml | sed 's/^#[^\n]*//g' > test2.qml
works pretty well for simple C style #ifdefs. Scripts can feed it your 
buildvars as defines and there you go.

>
> > This model should make application development less painful for
> > developers, not more.
> 
> This looks like the next case of a missing reality check.
> 
> 1. It's not the first time this discussion comes up, started
> by people actually trying to use it. I take that as an indication
> that there a real problem somewhere.

It certainly looks like there is a real problem somewhere. But it's hard to 
nail down precisely what it is and whether it's worth fixing (worth in the 
sense of the design tradeoffs, not just effort). Not to mention what the 
solution could be that doesn't compromise details like 'interpreted language' 
or the application development workflow that QML is optimized for.

The problem I'm hearing currently is that "QtQuick 2 is too different from 
QtQuick 1", which isn't easy to fix considering the design goal was that 
QtQuick 2 would be completely different from QtQuick 1 in every way that was 
better and not merely different. I'm surprised that there are so few cases of 
incompatibilty, it makes me think that QtQuick 2 didn't change enough ;) .

> 2. Assuming that the normal case is to have a C++ backend around,
> the "preprocessor" model will be used for that part of the
> application anyway. So now there are _two_ models the developer
> has to take care of. How can that be an advantage?

The advantage is in having the two models of compiled C++ and interpreted, 
declarative, QML. This necessitates a lot of changes, you get very little 
above C++ if you just follow along with everything it does (see .ui compared 
to .qml).

> PS:
> > [...]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.
> 
> I think it's a safe assumption that Qt Quick 1 is in more widespread
> use than v2. [ 1/2 ;-) ]

Not inside this tower ;) . But I wasn't talking about comparing to the 
proliferation of an unreleased version. All the QtQuick 1 I've seen so far is 
on the dead Symbian and Maemo platforms. Even if there were many of those 
applications, how many are in continued development for both the old one and 
living platforms?

--
Alan Alpert