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" _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
