On Thursday 28 May 2009, Akmanalp, Mehmet A wrote: > On Thu, May 28, 2009 at 9:38 PM, Aaron J. Seigo <ase...@kde.org> wrote: > > Animation *a = Animator::fadeIn(item); > > Animation *b = Animator::add(a, Animator::bounce(item, timesToBounce)); > > a = Animator::while(b, Animator::blur(item, amount)); > > Animator::add(a, Animator::fadeOut(item)); > > // auto starts when event loop is hit again, unless a->stop() is called > > > > Animation *a = Animator::fadeIn(item); > > Animator::bounce(item, timeToBounce, a, Animator::Add); > > Animator::blur(item, amount, a, Animator::While); > > Animator::fadeOut(item, a, Animator::Add); > > Honestly, I think the add / while syntax is a little unintuitive, > which is a minus since we're trying to make things as simple as > possible. Also, what if want the blur to happen during the fadein > and the bounce? I don't see how you'd do this with add-while without > grouping the fadein and blur.
Animator::bounce(item, timeToBounce, a, Animator::While); Animator::blur(item, amount, a, Animator::While); not hard :) still won't catch every case (for which you'd need a proper timeline system). > > * means two phase learning curve (Animator's shortcut, then Kinetic) if > > you need to "graduate" from Add/While in Plasa::Animator to Kinetic's > > groups > > Following the previous statement, I'd say we just ditch add / while. > This way, it'd be more consistent with Kinetic *and* it'd be a little > more intuitive (imho). > > Even if we don't create a whole new language as Ivan proposes, we > could imitate it in the name of ease of use: > > Animator a; > a.animate(item, > a.series( > a.fadeIn(), > a.parallel( > a.blur(amount, time), > a.series( > a.bounce(timesToBounce), > a.flip() > ) > ), > a.fadeOut() > ) > ); this is really hard to read for me. is fadeOut in the series or in the parallel? (yes, in the series. .... still) and for animations that take more than one item? ....sniiiiiiiiiiiiiiiip... i wrote a whole bunch of thoughts and ideas and realized something: this is completely missing the point of what we're trying to achieve here. the primary goal is simple: * define common animations to be used by plasmoids. a secondary "nice to have" is: * allow the possibility of combining a few animations together so ... concentrating on the first one, it seems like an obvious path would be to create a way to create an animation with a given name, one or more items and some parameters and have it just go. grep'ing the current widgets for all occurrences of Animator::customAnimation might be a nice start, as would adopting a few widgets and making them spiffy. bottom line is that we have not even identified the real world use cases for the secondary goal of multiple animations. i bet they will not only be somewhat rare, but they will also be very limited. i'd be very surprised to see chains of more than 4-5 anims, and most often it would like be just one or two. in which case an API like this: Animation a(item); a.add(animator.fadeIn()); Animation b; b.setParallel(true); b.add(animator.blur(0.8)); b.add(animator.bounce(4)); a.add(b); a.addPause(10); // a.add(animator.pause(10));? a.add(animator.fadeOut()); a.run(250); // builds the qt animation objects and runs it all starts to look not bad as that would be the "degenerate" case with this being a more common case: Animation a(item1, item2); a.add(animator.flip()); a.add(animator.bounce(3)); a.add(animator.moveTo(destination)); a.run(250); or maybe we just do make people use QAnimationGroup and friends for these things and bind those into the JavaScript space. but anything more complex feels like shooting a mouse with an elephant gun. we have DUI coming for that. ;-P -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
