[Qt-qml] Top-level Animation element, not pauseable/stoppable?

[Charley Bay]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt-qml/attachments/20101114/ce63018c/attachment.html