On Fri, Dec 4, 2009 at 2:24 AM, Aaron J. Seigo <ase...@kde.org> wrote: > > hi all .. > > so, the animation API is going through its final set of changes for 4.4. > please take a look at it if you care to and give us feedback now before it's > too late (as defined by "we are shipping it in 4.4 and are committed to that > API"). > > the basic "shape" of the API is this: > > * Plasma::Animator becomes a factory for Plasma::Animations > > * Plasma::Animation IsA QAbstractAnimation with the bare essential pure > virtuals implemented and which takes a QGraphicsWidget that should be animated > > * Plasma::AnimationGroup IsA QAbstractAnimation that wraps a > QAbstractAnimationGroup (this is the part i'm least sure about atm...) and > makes switching from parallel to sequential easy (personally, i think Kinetic > should have made parallel vs sequential a property, not introduced two > different classes; it's a hassle).
The motivation behind was that the code was quite different for the two groups. We didn't want to have : - If else if else if else all over the place inside the code. Other point : QPauseAnimation * addPause ( int msecs ) QAbstractAnimation * currentAnimation () const QPauseAnimation * insertPause ( int index, int msecs ) This API don't make sense for a parrallel group. But what is the use case (concrete) where you want to switch the group from sequential to parrallel? > > however, if we feel that the parallel- > >sequential switching is not worth it, we can simply kill this class and make > people deal with the slightly unwieldy QAnimationGroup directly. i'm kind of > leaning in that direction, tbh, even though i dislike parts of > QAnimationGroup's design. > > basically, it's a QGrahicsView-specific set of Plasma-standardized animations > implemented in little convenience classes so that it's simpler to use Kinetic, > particularly from scripts but also C++. they still mix-and-match nicely with > plain Kinetic classes, so it's not an either-or-choice, these are just some > pre-made ones for us to use extensively throughout plasma code (less code, > more consistency) And animations integrate well with QML :D. > > we still have one large outstanding bit of work left, and that is to port the > animations away from the use of the previous API revision's "render()" method > and make them proper QAbstractAnimations. see the Fade animation for how this > should look if you'd like to pitch in. the ones with render calls still are: > > grow.cpp > pause.cpp > pulser.cpp > rotation.cpp > rotationstacked.cpp > > Slide should also probably have its internal QPropertyAnimation removed so > it's as simple/straightforward as Fade is. > > -- > 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 Development Frameworks > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
