[Development] Toolability of mixing QML and JS

Bubke Marco Marco.Bubke at digia.com
Wed Jun 26 13:35:26 CEST 2013


I think we mix WYSIWYG and direct manipulating. WYSIWYG is not the problem, we can simply send the 
expressions to the qml items. But direct manipulating is the other way around. It is from the graphics
representation to the text representation. E.g.

You could write:

Item {
  x: parent.leftPadding + 30
}

to describe a box model(like in HTML). But if we want to edit it's not so easy anymore. We could find out that we want only change 30, but because we know only the x value, we have to find out what the value of parent.leftPadding is. This complicates the already complicate transformation code. What about if you change the parent and this new parent has no leftPadding property? There are so many undefined cases that supporting some will lead to a "unexpected" behaviour. So we don't change x in this case at all. You have to do it on thw text level. If you use expressions in properties you are not anymore in the declarative world so we don't support this case anymore.

Maybe it is possible for some cases but it would be increase the complexity of our code. This would increase the
maintenance costs for a feature which could be much better described in many cases declarative with a clear interface in the items(in this case explicit is in my opinion much better because it is better understandable from the qml user perspective). Time which would be much more useful for other features. I think in our discussion we should not only see if it is possible but what are the costs, how useful it is, what is the outcome in the long run. Maybe we should learn what our decision have long time implications and if we have no clue about it we should stay away from them and add what we better understand. With the time they get most probably clearer.


More information about the Development mailing list