https://www.youtube.com/watch?v=cHrrR3KhvUk

Thanks for the insight into what is coming up. I had a minor panic attack 
though, which seemed to be shared with the first person to ask a question. If 
the property bindings are lazy evaluated, then all my QML code will be broken. 
I actively exploit the existing binding behavior of immediately evaluating 
dependent bindings.  I hope I am misunderstanding this, but I think this should 
continue to be the behavior.  I also I don't want to have to choose or specify.

However there may happy automatic middle ground. If the bindings are a terminal 
leaf node, then they can be lazy evaluated. However any binding that is in the 
middle of a binding chain must be immediately evaluated. I think this will 
satisfy everyone.

Given:
Item { id: item; property int x2: parent.x*2 }

If x2 is not used anywhere, it can be lazy evaluated. But the moment there is a 
onX2Changed or Item { x: item.x2 } then it must be immediately evaluated.  For 
something like QML Items and x it is probably not that interesting of an 
example.
But let's now assume there is QObject-derived class bing used in the QML engine 
and it declares property x which is not required to be immediately updated, 
then as long as nothing is connected to the xChanged signal, then all those 
updates can be deferred[1]. But the moment something does connect to it, then 
it can no longer be lazy-evaluated.

I don't know if this is what Lars meant? But I think it could work without 
giving me panic attacks ;-)

[1] If you need a less abstract example, think of a QObject-derived class that 
processes video frames and uses OpenCV to find a target, and it emits the x,y 
position of the target.  If nothing is connected x() never needs to be 
evaluated, but if I connect a CrossHair Item and bind to the x() and y() 
properties, then the binding has to be evaluated immediately to update the 
position in the UI.

I do have another concern that perhaps the lazy bindings might make it harder 
to find binding loops?

_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to