Qt Kinetic + Plasma Call For Ideas / Project Plan

[Ivan Čukić]

> > And, Trolls are already making declarative UI, so this would go perfectly
> > alongside that.
>
> that's actually a concern of mine; we're already going to be getting a DUI
> at some point, not sure we want to create a "simple DUI" of our own.

You're probably right, we should wait for DUI to become stable, so that we 
could just extend it to fit our purpose.

> these are already themable, really. nobody seems to care, but then we have
> pretty simple anims so there's not a lot to interpret differently.

Or nobody seems to know :)

As for 'does animations belong with the themes' question, I think yes - both 
are about controlling the visual part of it all. But, as I said, we should 
probably wait for that - so that we don't have the need to support both our 
old descriptive syntax and the new (Troll's) one.

The reason I proposed the descriptive language is that the proposed ideas:

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

have a really uncute syntax - it simply is not readable. The original idea is 
better looking (to me), but it will mean exposing two more classes to script 
engines, while (if I understood it correctly) those classes are not yet 
API/ABI stable.

>QAnimationGroup g;
>g.addAnimation(Animator::bounce(item, timesToBounce));
>g.addAnimation(Animator::blur(item, amount));
>
>QSequentialAnimation s;
>s.addAnimation(Animator::fadeIn(item));
>s.addAnimation(g);
>s.addAnimation(Animator::fadeOut(item));

Cheers