Apologies to Eduardo, I "replied" directly to him from his email off-list,
but meant to send it to the list as a follow-up (so here it is again):
FIRST UPDATE:
<snip, pause/resume for nested animations in top-level animation, including
open ticket QTBUG-15083>
Update, I'm still working with animations, and getting interesting
behavior. (Would like to see this ticket closed, unsure if current issues
relate to this ticket.)
My "work-around" top-level ParallelAnimation worked fine ... until I nested
in a top-level sequential animation (e.g., "MySequentialAnimation.qml").
Now, I get a helpful error on load (I really like these messages from the
QML engine to help me figure things out):
QML QDeclarativeParallelAnimation_
QML_6: setRunning() cannot be used on non-root animation nodes.
So, my work-around is no longer a work-around, and it's possible I'm
performing some kind of unlawful animation abuse.
WHAT I WANT (LOGICALLY):
SequentialAnimation {
id: myTopLevelAnimation
// pause and resume at this level required
SequentialAnimation {
id: myCountDownDelay
loops: 1
duration: 400
// Logically, should fire ONCE
}
ParallelAnimation {
id: myRealInfiniteAnimation
loops: Animation.infinite
// ...startable and stoppable...would be nice, but not required
}
}
Logically, I'm intending something like a top-level animation that has a
"countdown" or "delay" (which runs ONCE), and then an infinite loop for a
parallel animation that does many things.
For the top-level animation, I'd only be interested in pause/resume for the
infinite loop (I wouldn't care about pause/resume for the countdown).
However, I can even get over that, if I merely did start/stop on the
top-level animation (e.g., forcing me to always fully repeat the countdown
is fine for this case).
I *think* this error merely applies to my work-around (where I explicitly
pause/resume animations nested in myParallelAnimation), and that the case
above is not explicitly disallowed, right?
Is this how others would implement a countdown/delay to an infinite
animation (seemed like a good idea to me?)
SECOND UPDATE:
Of course, there are *zillions* of options: I'm currently experimenting
with binding the "delay countdown duration" inside the nested animation so
that it counts down, the parallel animation runs, and a property change
triggers to zero the countdown. So, in that case, the countdown animation
would occur *every* time (the parent is infinite, but the "countdown" and
"parallel" animations merely loop once), but every subsequent execution of
the "countdown" would have a "duration: 0". (I think that will work, but it
is a little weird having imperative "reset" code -- so I'm open to
alternatives.)
THIRD UPDATE:
After re-reading the QML docs for the zillion'th time (I'm slow -- sorry), I
found the most innocent sentence that *may* relate to the issue:
<http://doc.qt.nokia.com/4.7/qml-animation.html>
"By default, animations are not running. Though, when the animations are
assigned to properties, as property value sources using the *on* syntax,
they are set to running by default."
AHA! You little bugger you. That's what I'm doing: The *nested* parallel
animations are *bound*, so by default, the are *running*! (Seems like fine
default behavior.) However, in my case, the "parent" animation is *not*
bound -- so I think upon construction, the children *do not* have the same
running/paused state, and somehow, my work-around was necessary to get them
to the same state. That makes sense: Because "set" operations probably
check the parent to decide if *anything* is to be done (to avoid signal
recursion), these set operations would similarly *not* check to see if the
"parent" and "nested" happen to have the same state. (After all, they
should not, since you're not supposed to set the nested state -- the docs
said that setting nested state should be ignored.)
Anyway, that might be interesting to people learning about animations (it
was for me): Animations default to *not* running, unless they are bound to
properties, at which point they default to running. (The QML internal bug
seems to be corner-case synchronization between the parent and nested
running states, when they have *different* default states; that might be
helpful to the bug-fixer guy at Nokia.)
(At present, I still have pause/resume problems -- can't pause or stop at
all, animation says it's not started no matter what I do, even though I see
the animation running. I'll keep banging on it.)
--charley
_______________________________________________
Qt-qml mailing list
Qt-qml@trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-qml
