Plasma + QT Kinetic Preliminary Design Decisions

[Akmanalp, Mehmet A]

> .. and for parallel or sequential it would create, internally, QParallelAG
> and/or QSequentialAG objects?
...
> 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.
So, I could:
* Be an adapter, have a QAnimationGroup object as an internal property
that we instantiate as either QSeqAG or QParrAG depending on what we
get in the constructor (maybe we can be lazy in instantiating it i.e.
till the user does .setParallel() or whatever)
* Have a static factory method that returns my subclass of QSAG or
QPAG and do the important stuff in those.
I think having the latter is a better idea in terms of the "do one
thing, do it well" principle.  Also, it's cleaner since we don't have
to deal with stuff like keeping track of whether the object is
internally a QSAG or QPAG. How does this sound?

> you'd create them all before it hits the event loop.
No, I mean this: Since we chain the methods together, when it's going
to tick. Take the old example, we might have a situation like this:
> Animation a,b;
> a.setParallel(true)
>  .add(Animator.blur(0.6))
->> tick here
>  .add(Animator.bounce(2))
> b.add(a)
>  .add(Animator.pause(1))
Oops, we were gonna add more stuff afterwards but the animation
already started and now we have a race issue, right?

>> * 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 ;)
Since Alexis said the current QGraphicsItemAnimation only supports one
item at a time, I think we shouldn't bother with this at this point.
This feature is just an added bonus, if the developer wants to use it
on multiple items, he can just make a new one.

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

> 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.
Sounds good.

-- 
~ mali (http://constant.inople.net/)