Qt Kinetic + Plasma Call For Ideas / Project Plan

[Aaron J. Seigo]

On Thursday 28 May 2009, Akmanalp, Mehmet A wrote:
> On Thu, May 28, 2009 at 9:38 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > Animation *a = Animator::fadeIn(item);
> > Animation *b = Animator::add(a, Animator::bounce(item, timesToBounce));
> > a = Animator::while(b, Animator::blur(item, amount));
> > Animator::add(a, Animator::fadeOut(item));
> > // auto starts when event loop is hit again, unless a->stop() is called
> >
> > Animation *a = Animator::fadeIn(item);
> > Animator::bounce(item, timeToBounce, a, Animator::Add);
> > Animator::blur(item, amount, a, Animator::While);
> > Animator::fadeOut(item, a, Animator::Add);
>
> Honestly, I think the add / while syntax is a little unintuitive,
> which is a minus since we're trying to make things as simple as
> possible. Also, what if  want the blur to happen  during the fadein
> and the bounce? I don't see how you'd do this with add-while without
> grouping the fadein and blur.

Animator::bounce(item, timeToBounce, a, Animator::While);
Animator::blur(item, amount, a, Animator::While);

not hard :)

still won't catch every case (for which you'd need a proper timeline system).

> > * means two phase learning curve (Animator's shortcut, then Kinetic) if
> > you need to "graduate" from Add/While in Plasa::Animator to Kinetic's
> > groups
>
> Following the previous statement, I'd say we just ditch add / while.
> This way, it'd be more consistent with Kinetic *and* it'd be a little
> more intuitive (imho).
>
> Even if we don't create a whole new language as Ivan proposes, we
> could imitate it in the name of ease of use:
>
> Animator a;
> a.animate(item,
>   a.series(
>     a.fadeIn(),
>     a.parallel(
>       a.blur(amount, time),
>       a.series(
> 	a.bounce(timesToBounce),
> 	a.flip()
>       )
>     ),
>   a.fadeOut()
>   )
> );

this is really hard to read for me. is fadeOut in the series or in the 
parallel? (yes, in the series. .... still)

and for animations that take more than one item?

....sniiiiiiiiiiiiiiiip...

i wrote a whole bunch of thoughts and ideas and realized something: this is 
completely missing the point of what we're trying to achieve here.

the primary goal is simple:

* define common animations to be used by plasmoids.

a secondary "nice to have" is:

* allow the possibility of combining a few animations together

so ... concentrating on the first one, it seems like an obvious path would be 
to create a way to create an animation with a given name, one or more items 
and some parameters and have it just go. grep'ing the current widgets for all 
occurrences of Animator::customAnimation might be a nice start, as would 
adopting a few widgets and making them spiffy.

bottom line is that we have not even identified the real world use cases for 
the secondary goal of multiple animations.

i bet they will not only be somewhat rare, but they will also be very limited. 
i'd be very surprised to see chains of more than 4-5 anims, and most often it 
would like be just one or two.

in which case an API like this:

Animation a(item);
a.add(animator.fadeIn());
Animation b;
b.setParallel(true);
b.add(animator.blur(0.8));
b.add(animator.bounce(4));
a.add(b);
a.addPause(10); // a.add(animator.pause(10));?
a.add(animator.fadeOut());
a.run(250); // builds the qt animation objects and runs it all

starts to look not bad as that would be the "degenerate" case with this being 
a more common case:

Animation a(item1, item2);
a.add(animator.flip());
a.add(animator.bounce(3));
a.add(animator.moveTo(destination));
a.run(250);

or maybe we just do make people use QAnimationGroup and friends for these 
things and bind those into the JavaScript space.

but anything more complex feels like shooting a mouse with an elephant gun. we 
have DUI coming for that. ;-P

-- 
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/20090528/1151003d/attachment.sig