Plasma + QT Kinetic Preliminary Design Decisions

[Alexis Ménard]

On Thu, Jun 4, 2009 at 7:16 PM, Aaron J. Seigo <aseigo at kde.org> wrote:

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


There is unfortunatly already a sucky QGraphicsItemAnimation...

Actually animation is related to one target at the time...
So you will need to do extra work to apply it on several targets...

But that is a valuable feedback, i can talk with some guys here, same
animation but
multiple targets.


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

mmm looks like strange...I mean having an extra class for grouping is
probably better
AND more readable, when you read you can see that you put the blur animation
in a group,
and the API for Animation will be much more clean. As aaron said, go ahead
man, we prefer
to review h files and you will face implementation issues so go ahead.


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


Yep as soon as the old stuff is properly documented as obslelete and you
hide it deeply in the h file, that's how we do in Qt.

Having a new file can be better if the choice is possible.


>
> the other option would be AnimationFactory, but then things gets confusing
> in

libplasma imho. i'd much rather just retro-fit Animation.


I really like the factory concept : give me blur animation object which i
can set-up and put into groups if needed...


>
> --
> 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
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20090604/4327cabe/attachment.htm