On Thu, Jun 4, 2009 at 7:16 PM, Aaron J. Seigo <ase...@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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
