Hi --- Em qui, 3/12/09, Aaron J. Seigo <ase...@kde.org> escreveu: > De: Aaron J. Seigo <ase...@kde.org> > Assunto: animation api changes > Para: "Plasma" <plasma-devel@kde.org> > Data: Quinta-feira, 3 de Dezembro de 2009, 23:24 > 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). 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. Well as all the animations are qabstractanimations we can use all the animations in qXanimationgroup too. > > 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) > > 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.
In fact we are removing QPropertyAnimation of all animation(until the complex one like rotationstacked) > > -- > 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 > > -----Anexo incorporado----- > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ____________________________________________________________________________________ Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
