Thanks, Eduardo! (Very helpful.) (more responses below ...)
Attached is my example. Click the blue rectangle and it will start
> animating. Click it again to stop. Interestingly the same does not happen
> for the orange one. The only difference is how I set the target of the
> animation (the first one I use its ID, the second one I use "parent"). And
> it fails silently in the second case.
>
> Interesting ...
> WRT to your example:
>
> On Wed, Nov 3, 2010 at 10:16 PM, Charley Bay <charleyb...@gmail.com>wrote:
>
>>
>> //FILE: MyParallelAnimation.qml
>> ParallelAnimation {
>> loops: Animation.infinite
>> running: true
>> SequentialAnimation on someVal1 { loops: Animation.infinite; ..... }
>> SequentialAnimation on someVal2 { loops: Animation.infinite; ..... }
>> SequentialAnimation on someVal3 { loops: Animation.infinite; ..... }
>> }
>>
>>
> It called my attention you are using the "SequentialAnimation on something"
> syntax. Is that true or was it just a shortcut you used to write the email?
>
>
Yes, I'm actually using the "SequentialAnimation on someVal {}" syntax.
More specifically, the *reason* I have a separate Animation object is
because "there is a lot going on", and I create it to manage a set of
dynamically changing values:
//FILE: MyParallelAnimation.qml
ParallelAnimation {
loops: Animation.infinite
property real someValue1: 1.1
property real someValue2: 2.2
property real someValue3: 3.3
SequentialAnimation on someVal1 { loops: Animation.infinite; ..... }
SequentialAnimation on someVal2 { loops: Animation.infinite; ..... }
SequentialAnimation on someVal3 { loops: Animation.infinite; ..... }
}
...then, the "myParent" uses those values directly:
//FILE: MyParent.qml
Item {
property alias someValue1: myAnimation.someValue1
property alias someValue2: myAnimation.someValue2
property alias someValue3: myAnimation.someValue3
MyParallelAnimation {
id: myAnimation
}
}
IMHO, this is very elegant and clean. A previous design put "everything" in
"MyParent.qml", but that was really hard to maintain (because there was so
much stuff in there).
Further, the new design gives me the benefit that I can use the animated
values that are *not* tied to a specific Item{} (which for the current
system I sometimes want to do -- these animation values happen to be doing
"physics engine" stuff.)
> Also, it seems you're setting Infinite loops on the internal animations. I
> think this is not supported. I mean, you loop the whole thing (the
> parallel), not individual ones.
>
>
I did not *used* to have the infinite loops in the nested
SequentialAnimation elements. However, I *only* added them because without
them, the animation would only run a single time. It took me a while to
figure out -- I made the parent ParallelAnimation infinite, but it would
only run a single time. After I made the nested ones infinite *also*, the
parent would now (also) run infinitely. (I didn't know what should be the
proper behavior, the current works through trial-and-error.)
<snip, binding nested to parent>
>>
>
> This should not be a problem, unless something is overriding the binding.
>
A "would be nice" might be a method or mechanism to "test" if a binding
*exists* (for debugging purposes). (I sometimes set bindings, to later find
out that the binding is not there, and it would be nice to be able to test
for that. I understand there are many legitimate reasons why "breaking" or
"failure to set" the binding might happen.)
>
>
>>
>>
> I assume "stop/start" would merely trigger the animation to start from the
>> *beginning*, where "pause/resume" would keep values where you left them?
>> (Or when should you use them differently?) For example, if I had "loops:
>> 1", does "stop/start" or "pause/resume" behave differently after the full
>> loop was completed the first time?
>>
>
> Yep,
>
> running, start() and stop() cause it to go to start from the beginning
> paused, pause() and resume() cause it to resume from where it was paused.
> Note, you cannot resume an animation that is not running yet.
>
>
If you "start" an animation that was previously "stopped", does your
statement imply that *both* the "from" values are restored to their original
values, *and* the loop count is restored to its original (maximal) value? (I
guess I could just test that ...)
<snip, other pause info, QDeclarative/QObject hierarchy>
Thanks! This is very helpful.
--charley
_______________________________________________
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml
