Re: [Development] Lar's QtCore 6 talk

2020-05-18 Thread Lars Knoll
Hi Jason,

> On 16 May 2020, at 22:27, Jason H  wrote:
> 
> 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 ;-)

No need for panic attacks :)

Lazy binding evaluation means that we will do this where possible behind the 
scenes. The new property system works this way by default. This is possible, as 
long as the property is only used in binding expressions.

If you however have change handlers connected to the property, we will of 
course need to evaluate the binding immediately (as we can’t know the possible 
side effects of the change handler).

If you’re interested in the details, have a look at qproperty.h/cpp in the dev 
branch (look for the QPropertyChangeHandler class and the 
ObserverNotifiesChangeHandler flag in the implementation).

Cheers,
Lars

> 
> [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

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


[Development] Lar's QtCore 6 talk

2020-05-16 Thread Jason H
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