<snip, top-level ParallelAnimation>
Eduardo respondeth:
In what fashion are you using your animation? I'm asking that because in
> Quick you can use animations in several ways, to name a few:
>
> - Inside a Behavior
> - Inside a Transition
> - As a stand-alone element you explicitly call start and stop
> - As an event handler onClicked: Animation { blah }
>
The third one, stand-alone element, hard-coded into a parent.
Curiously, if it's hard-coded to "running" at start, I can *never* stop it.
If it's hard-coded to "paused/stopped" at start, I can *never* start it. I
assume this means the value is being set, but the binding is lost somewhere
along the way (but I set property or call functions directly on the
ParallelAnimation, so I don't see how that can be broken).
I created a "top-level" element:
//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; ..... }
}
...then, I instantiate it as an inline member of some parent:
//FILE: MyParent.qml
Text {
MyParallelAnimation {
id: myMyParallelAnimation
}
}
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 ;-)
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?
> What you mentioned can be a bug, so please provide us with a little bit
> more info on how are you using it, IOW, where are you writing
> MyParallelAnimation {} ?
>
>
If the above doesn't make sense, I can try to rip out a small example that
illustrates the behavior.
I emailed the list because I'm trying to understand if the "running" and
"paused" attributes were behaving properly. For example, I understand the
corner cases that exist based on the "alwaysRunToEnd" property, and the
chance that "paused" may be set while the animation completes its cycle, but
other than "run to end" corner cases (that I'm not using), should "running"
and "paused" *always* reflect the actual animation? (I assume "yes", but
I'm not sure?)
> WRT to the base class of animations, no, they are just plain QObjects, not
> QDeclarativeItems. The latter is reserved for types that belong to the scene
> graph, and potentially do painting, while the former is for support objects
> like animations, states, etc.
>
>
Excellent. Thanks! That's the type of information I was looking for.
(Is there a chart somewhere of all Item{}/QDeclarativeItem derived things,
and all other QObject derived things?)
Thanks!
---charley
_______________________________________________
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml
