[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