[Development] QML: grouping property changes for a single callback invocation

[Alan Alpert]

On Sun, 4 Mar 2012 03:15:40 ext Alberto Mardegan wrote:
> Hi all,
>   sorry for the intricated subject, I couldn't find a concise and
> understandable way to express what I mean. :-)
> 
> Often it happens to me that I want to run some code when two or more
> properties change on a QML object. A real life example is the contentX
> and contentY properties from Flickable.
> 
> Now, I don't care which one of these properties change: suppose that I
> just want to do this:
> 
> =======
> onContentXChanged: updatePos()
> onContentYChanged: updatePos()
> 
> function updatePos() {
>     myObject.setPos(Qt.Point(contentX, contentY))
> }
> =======
> 
> Now, the code above has a couple of issues:
> 
> 1) Performance: if both contentX and contentY change, updatePos() will
> be called twice, unnecessarily.
> 
> 2) Jagginess (and correctness): when the flickable contents move from
> (0, 0) to (1, 1), myObject will first have its position set to (0, 1),
> which is not correct.
> 
> 
> So, question time:
> 1) Am I missing something, or does the situation stand as I described it?

It's pretty much as you described. With the slight addendum that what you're 
asking for is probably not possible (in the general case). X and Y are 
independent variables, one may change without the other. So the code can't 
just wait for a signal which may or may not ever come. If you have a solution 
for this problem, I'm all ears :) .

There are some cases, like some X/Y changes, where the code setting it knows 
that it is going to set both 'at the same time'. In this case, the API should 
expose the combined property so that you can deal with that. In the QQuickItem 
case, we have a 'QPointF pos' property which you can bind to for combined X/Y 
updates. This has the advantage that singular X or Y updates also update pos 
and so the binding will work then too. But this is the best solution that we 
have at the moment, objects with knowledge that some properties frequently 
update together need to expose that in their API.

> 2) Can we do something about it for Qt5? :-)

We just passed feature freeze for Qt 5.0, I don't think it's possible to make 
QML language changes in 5.0 any longer. It might be possible to make some 
kinds of language changes in 5.x, if someone has a really good idea, but not 
5.0. So at the very least, that discussion may drag out for some time.

If there are just some API changes you want added to the elements (for 
example, adding pos to Item if we didn't already have it) then that is also 
probably too late for getting into 5.0. But it will be very easy to prepare 
those changes for 5.1 if there's a suggestion that everyone likes.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks