<br><br><div class="gmail_quote">On Thu, Jun 4, 2009 at 7:16 PM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thursday 04 June 2009, Akmanalp, Mehmet A wrote:<br>
> Hello,<br>
> I wanted to distill the discussions made previously on the list + my<br>
> thoughts and findings into something more concrete, so I can start<br>
> making a prototype soon.<br>
<br>
</div>great :) also, i find writing the prototype code sooner rather than later<br>
helps flush out a LOT of things we might otherwise miss. don't wait for a<br>
completed specification to start sketching out the API: those two things<br>
should go hand-in-hand.<br>
<div class="im"><br>
> * For grouping, our Animation object (or whatever) can just subclass<br>
> QAnimationGroup. QAG supplies all we need, no need to go lower to<br>
> QAbstractAnimation imho.<br>
<br>
</div>.. and for parallel or sequential it would create, internally, QParallelAG<br>
and/or QSequentialAG objects?<br>
<div class="im"><br>
> This way, we can interopt with other Kinetic<br>
> stuff nicely. IIRC, it was also mentioned the js / ruby / python APIs<br>
> will not need to know about Kinetic.<br>
<br>
</div>as long as QAG is kept to an internal detail and there's no need for users of<br>
the code to ever call methods in QAG (or QAbstractAnimation) then we'll be<br>
fine.<br>
<div class="im"><br>
> * Now that I thought of it, I'm not exactly sure what aseigo meant by<br>
> "auto-start-when-event-loop-enters magic". Would we make QAG start<br>
> automagically with the next tick of the event loop. If so, providing<br>
<br>
</div>that's the idea.<br>
<div class="im"><br>
> an option to not do this would also be neat, so people using our stuff<br>
> in conjunction with Kinetic stuff can have more freedom. However, how<br>
<br>
</div>correct; that was event in the code sketches in my previous emails.<br>
<div class="im"><br>
> would we detect that an animaton object is done being created?(Maybe<br>
> we're going to add more properties to it.)<br>
<br>
</div>you'd create them all before it hits the event loop.<br>
<div class="im"><br>
> * Should we set the object to animated in the Animation ctor or set it<br>
> later with a function such as .setObject()?<br>
<br>
</div>if the Animation object does not operate properly without such an object, i'd<br>
suggest putting it in the ctor; if the intention is to create Animations and<br>
then apply them over and over to different objects, then the setter makes<br>
sense. either way, the setter should be there (as it is with other<br>
QAbstractAnimators that work on specific kinds of items)<br>
<br>
my only concern would be that Qt doesn't then introduce a<br>
QGraphicsItemAnimation or whatever and obsoletes our code there ;)</blockquote><div><br>There is unfortunatly already a sucky QGraphicsItemAnimation...<br><br>Actually animation is related to one target at the time...<br>
So you will need to do extra work to apply it on several targets...<br><br>But that is a valuable feedback, i can talk with some guys here, same animation but<br>multiple targets.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="im"><br>
> * For consistency / compatibility between all the different language<br>
> bindings, returning a reference instead of using something like the <<<br>
> operator as a grouping shortcut seems like a better idea.<br>
<br>
</div>+1<br>
<div class="im"><br>
> * Example (looks a bit cleaner in monospace):<br>
> Animation a,b;<br>
> a.setParallel(1)<br>
<br>
</div>well, a.setParallel(true) ;)<br>
<div class="im"><br>
> .add(Animator.blur(0.6))<br>
> .add(Animator.bounce(2))<br>
> b.add(a)<br>
> .add(Animator.pause(1))<br>
<br>
</div>hm... how will the implementation of this look like? since objects a and b<br>
will be a QAnimationGroup, when a is added to b it will need to check for<br>
parallel, etc. and set up the correct kinetic stuff internally, correct? that<br>
could get a bit messy in the implementation.<br>
</blockquote><div><br>mmm looks like strange...I mean having an extra class for grouping is probably better<br>AND more readable, when you read you can see that you put the blur animation in a group,<br>and the API for Animation will be much more clean. As aaron said, go ahead man, we prefer <br>
to review h files and you will face implementation issues so go ahead.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
if it does get too messy, one option might be to make Animation not a<br>
QAnimationGroup but give it an accessor that would return a new<br>
QAnimationGroup based on its internal status.<br>
<br>
probably i'm getting a bit ahead of all of this speaking of implementation<br>
details ;)<br>
<div class="im"><br>
> * I'm still lacking a decent name for the class. SimpleAnimator?<br>
> KineticAnimator? Animator2? :P Maybe something shorter and easier to<br>
> type? Dunno.<br>
<br>
</div>can we just extend Plasma::Animator with the new methods and deprecate all the<br>
old stuff?<br>
<br>
to keep the implementation from becoming mixed up with all the old crufty<br>
stuff, we could move the current animator.cpp somewhere else<br>
(deprecated/animator.cpp? private/animator.cpp?) and name the new, fresh and<br>
happy implementation file animator.cpp.</blockquote><div><br>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.<br> <br>Having a new file can be better if the choice is possible.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
the other option would be AnimationFactory, but then things gets confusing in </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
libplasma imho. i'd much rather just retro-fit Animation.</blockquote><div> <br>I really like the factory concept : give me blur animation object which i can set-up and put into groups if needed...<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<font color="#888888"><br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Software<br>
<br>
</font><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br>