Hi Charley, I've tried running some tests myself and I could in fact have an animation in a separate file which I could start and stop at will. Not sure if we're trying different use cases or if there's a difference in Qt version for instance.
However I did find something that can be a bug (I'll open that in bugzilla).
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.
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?
In my example I used the syntax:
ParallelAnimation {
SequentialAnimation {
PropertyAnimation { }
(...)
}
}
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.
Probably unrelated, but I "bind" properties from within MyParallelAnimation
> to properties in MyParent. Further, I alias the "running" attribute up
> through the MyParent also. However, that's probably unrelated, because
> everything works (except I can't MyParallelAnimation to stop nor pause ;-)
>
This should not be a problem, unless something is overriding the binding. A
way of doing this is to add a debug statement to the animation, as I did in
my example:
ParallelAnimation {
onRunningChanged: console.log("Root animation running is " + running)
(...)
}
This will let you know whether the running information is making its way
through the bindings until the animation. In my case it is, both for the
blue and orange rects... Yet the second doesn't work.
>
>
>
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.
should "running" and "paused" *always* reflect the actual animation? (I
> assume "yes", but I'm not sure?)
>
To the best of my knowledge, Yes! However when we have a composed
animation, this is only true for the outer animation. You should not pause
or stop the internal ones. In fact, in my tests their state is never changed
(running is always false for the internal ones).
>
> (Is there a chart somewhere of all Item{}/QDeclarativeItem derived things,
> and all other QObject derived things?)
>
Not sure whether there's a chart, but you have the list of elements here
http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeelements.html
Rule of thumb is you can assume that everything you see, plus Item { }, are
QDeclarativeItems. Everything else in that list should be QObjects.
Cheers,
Eduardo
--
Eduardo M. Fleury
OpenBossa - INdT
http://eduardofleury.com/
http://www.openbossa.org/
MyAnimation.qml
Description: Binary data
main.qml
Description: Binary data
_______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
