animation api changes

[Alexis Ménard]

On Fri, Dec 4, 2009 at 2:24 AM, Aaron J. Seigo <aseigo at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>