[Development] QML engine changes

[Bubke Marco]

Hi

Alan Alpert:
>> The staunch refusal to provide reasonable interfaces to the individual layers
>> of the Qt Quick stack adds insult to injury, no matter how you put it.

> Good thing we never did that. In fact, V4+V8->V4VM and
> QtDeclarative->QtQml+QtQuick both promise to improve the interfaces
> between individual aspects of the QtQuick stack.

Do you really believe the C++ interface of Qml is well designed? E.g. the list interface is only providing clear,
so if we change the one element in the list, we have to clear the list and build it new. But append has only the 
ability to add one element. So it is really slow because for every append so much happens in the scene graph etc..
This really slows the designer down. Next it the refresh of the bindings which has to happen for example, if we add
a new id. This is really slow and happens at the item creation time. The whole Qml/Quick part was never design to
be editable by a designer and we have to work around it. Other item in this context would be for example componentComplete, the QObject model is not fitting many Qml requirements and so instead of development a better object model there are now many layers on top of it with all the caching structures which are really complex.
In my opinion clear C++ interface would be really help Qml, it would be no problem if the interface would be changed over time but poking around in private member classes and changing variables is not very maintainable. I could go on but I hope you get the the tooling picture.

Your story is maybe saving you cost but in my opinion the over all costs are much higher. Also the code readability
and so the maintainability would improved by clear interfaces and structures. I know this is not cool and boring but 
in the end a source text which is more readable is better understandable, so changes would be more easy.

> Now maybe these don't solve your specific toolability concerns. But as
> you haven't mentioned any specific concerns yet, I can only address
> the problems I'm aware of. As I said, I'd like to hear your
> toolability complaints about JS embedded in QML, in a separate thread.
> It will almost certainly be easier to address them with the new JS
> engine than the old one.

My general concern is that Qml is designed from the text(vi) perspective, and not so much from the tool perspective.

One example for it:

you can write

font.bold: true
font.italic: true

and 

font {
  bold: true
  italic: true
}

This is maybe cool from the text perspective but the tools have to support both cases and this is producing work.
What about the Python approach where features are only added if they are really produce a advantage.

Sorry for the rant, but I really believe we need a more global approach(development story) to Qml, a wider scope
and if we are not sure we should ask the other guy what they think about the change.