[Development] Suggestion on QML portability

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Mon Jul 16 21:19:41 CEST 2012


I am afraid I am in "Can't resist" mode today...

On Mon, Jul 16, 2012 at 01:50:42PM +1000, Alan Alpert wrote:
> [...]
> 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?

> 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.

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?

Andre'

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 ;-) ]

[1] I am not necessarily refering to the exact #include, #if etc
syntax, but the concept of "easy-to-use 'compile' time conditionals"



More information about the Development mailing list