Plasma + QT Kinetic Preliminary Design Decisions

[Aaron J. Seigo]

On Thursday 04 June 2009, Akmanalp, Mehmet A wrote:
> Hello,
> I wanted to distill the discussions made previously on the list + my
> thoughts and findings into something more concrete, so I can start
> making a prototype soon.

great :) also, i find writing the prototype code sooner rather than later 
helps flush out a LOT of things we might otherwise miss. don't wait for a 
completed specification to start sketching out the API: those two things 
should go hand-in-hand.

> * For grouping, our Animation object (or whatever) can just subclass
> QAnimationGroup. QAG supplies all we need, no need to go lower to
> QAbstractAnimation imho.

.. and for parallel or sequential it would create, internally, QParallelAG 
and/or QSequentialAG objects?

> This way, we can interopt with other Kinetic
> stuff nicely. IIRC, it was also mentioned the js / ruby / python APIs
> will not need to know about Kinetic.

as long as QAG is kept to an internal detail and there's no need for users of 
the code to ever call methods in QAG (or QAbstractAnimation) then we'll be 
fine.

> * Now that I thought of it, I'm not exactly sure what aseigo meant by
> "auto-start-when-event-loop-enters magic". Would we make QAG start
> automagically with the next tick of the event loop. If so, providing

that's the idea.

> an option to not do this would also be neat, so people using our stuff
> in conjunction with Kinetic stuff can have more freedom. However, how

correct; that was event in the code sketches in my previous emails.

> would we detect that an animaton object is done being created?(Maybe
> we're going to add more properties to it.)

you'd create them all before it hits the event loop.

> * Should we set the object to animated in the Animation ctor or set it
> later with a function such as .setObject()?

if the Animation object does not operate properly without such an object, i'd 
suggest putting it in the ctor; if the intention is to create Animations and 
then apply them over and over to different objects, then the setter makes 
sense. either way, the setter should be there (as it is with other 
QAbstractAnimators that work on specific kinds of items)

my only concern would be that Qt doesn't then introduce a 
QGraphicsItemAnimation or whatever and obsoletes our code there ;)

> * For consistency / compatibility between all the different language
> bindings, returning a reference instead of using something like the <<
> operator as a grouping shortcut seems like a better idea.

+1

> * Example (looks a bit cleaner in monospace):
> Animation a,b;
> a.setParallel(1)

well, a.setParallel(true) ;)

>  .add(Animator.blur(0.6))
>  .add(Animator.bounce(2))
> b.add(a)
>  .add(Animator.pause(1))

hm... how will the implementation of this look like? since objects a and b 
will be a QAnimationGroup, when a is added to b it will need to check for 
parallel, etc. and set up the correct kinetic stuff internally, correct? that 
could get a bit messy in the implementation.

if it does get too messy, one option might be to make Animation not a 
QAnimationGroup but give it an accessor that would return a new 
QAnimationGroup based on its internal status.

probably i'm getting a bit ahead of all of this speaking of implementation 
details ;)

> * I'm still lacking a decent name for the class. SimpleAnimator?
> KineticAnimator? Animator2? :P Maybe something shorter and easier to
> type?  Dunno.

can we just extend Plasma::Animator with the new methods and deprecate all the 
old stuff?

to keep the implementation from becoming mixed up with all the old crufty 
stuff, we could move the current animator.cpp somewhere else 
(deprecated/animator.cpp? private/animator.cpp?) and name the new, fresh and 
happy implementation file animator.cpp.

the other option would be AnimationFactory, but then things gets confusing in 
libplasma imho. i'd much rather just retro-fit Animation.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090604/9c6c0ed7/attachment.sig