QML Animations: not specified how they react to property changes while running

Summary

Documentation on Animation and Transitions in Qt Quick is pretty comprehensive, except one asspect.

It does not specify what should happen if target properties' values were to change while an animation is running.

Why is this a problem?

Through the trial and error process I discovered that it seems like all animation components "memorize" (cache) their from/to values at start, and never let them go until they finish. Which is never, if they are Infinite (this fact is documented at least, though not absolutely obvious).

Thus, changing values in the middle of e.g. a SequentialAnimation loop does nothing: you'll get your onFromChanged etc. events up and running, but internally the animation would keep reverting values back to initial.

Steps to reproduce

…or rather a showcase. I implemented Android/Google/YouTube spinner/loader as a BusyIndicator control in pure QML with QtQuick.Shapes and a bunch of animations.

Turns (no pun Nintended) out, it's nearly impossible to implement such a spinner exclusively in declarative manner, because it is fundamentally procedural: in addition to uniform clockwise rotation, at the end of each dynamic spin its tail matches up with its head, and that shall become their new base/reference angle. Naturally, I tried to use PropertyAction, and ScriptAction. Both failed for aforementioned reasons.

Instead, to make it work, I'm using this dirty hack:

1. Set loops to 1.
2. Make sure animation changes property's value in the end of a loop.
3. Add signal handler:

    onFinished: {
        if (control.running) {
            start()
        }
    }

Apart from that, I'm still wrapping arc's startAngle around 360 in ScriptAction to prevent it from growing unbounded. But that's off-topic. The point is: Animations may require weird undocumented bikeshedding to make things work.

Full code is on this GitHub Gist.

Preferred solution

First, I'd like documentation to be explicit about it. Write few paragraphs, provide examples, explain to users what's gonna happen.

Second, I think multi-loop animations, including Infinite ones of course, should be better supported by framework. It is certainly not possible to change current behavior without breaking backward compatibility. But it should be possible to introduce a new property to control whether animations should clear their cache and re-evaluate their boundary values (and obviously disable such behavior by default).