N9 Developer - Qt Quick best practices, property bindings in QML

Re: Qt Quick best practices, property bindings in QML

2011-11-19T16:56:27Z

What is cool with states is when you need animations that are different from one transition to another.

Also, if more than one properties are need conditionals, it could be a bit cumbersome to maintain/update the code while prototyping your whole component logic...

I've no preference on one from another. However, from a performance point of view, a more detailed comparison might be interesting.

2011-11-18T20:34:24Z

Michael, generally I do agree with you, not least because explicit states tend to result in more lines of code. I came across the specific situation I described recently in some code that suffered a bit from ad-hoc requirements specification, and I think with a little refactoring the whole problem would've gone away. It's just strange that explicit states are so redundant: they're not too useful as data, and neither are they very handy as API.

2011-11-18T18:34:50Z

@ilkkal, I would still consider property bindings more robust, even in that case.

If the conditionals for the property bindings become too complex, then the introduction of new custom properties can help to simplify (though any new property means new state, so there's a natural trade-off).

Picking up your example where "one property has major effects on layout, label texts etc": This sounds as if you were using a dedicated Style component, and that's one of the places where I really like to use property bindings.
Then, whenever the Style component changes, I don't have to worry that some dependent property will be forgotten in the update.

If we consider transition animations (or properties that are explicitly used for transition animations), then that's *usually* not part of your core application logic, but rather pretty isolated UI effects.That is, your application should still work even if you removed the transition animations.

For those, it can make more sense to use explicit state handling instead.

2011-11-18T10:43:23Z

Do you find that bindings should win over state handling even when the properties of a large number of elements depend on some property change? Say there is a property that has major effects on layout, label texts etc. Would you rather sprinkle the code with conditionals, or have all the changes grouped as PropertyChanges in a State?

table fixed

2011-11-14T09:05:02Z

thank you for the pointer.

2011-11-12T17:51:46Z

I suppose there is a mistake in the table. Istead of -5 -3 -2 should be -5 -3 2

security testing

2011-11-11T17:27:06Z

testing