Animators fps, Plasma KCM, Physics and Duration control

[Aaron J. Seigo]

On Sunday 06 January 2008, Riccardo Iaconelli wrote:
> Hello,
> sorry for the subject a bit criptic, I'll try to explain what I've just
> thought in the shower.
>
> So, I was patching Phase for the duration control problem.
> Patching it, I thought that being able to control fps from the plasmoid
> would be good, after all, not all the animations require the same number of
> fps.

this has two unfortunate side effects: the API becomes even less readable than 
it already is (Phase is not my favourite piece of work =) and it will 
encourage people to do things they shouldn't.

what are the use cases for varying the fps, exactly? you provide this one:

> But then, the code was already querying the animator for them, which is
> obviously right... if someone wants to do a very resource-conservative
> animator, he will probably want to drastically reduce the number of fps.

or just skip frames. you don't have to render each frame on request if you 
don't want to.

> Phase::moveItem(QGraphicsItem *item, int duration, Movement movement, const
> QPoint &destination, Phase::Smoothness smoothness)

i really am not overly comfortable with adding a duration. the Animator is 
really the only class that *really* knows how long the animation should last. 
if anything, add more Movements (e.g. SlideInFast).

> where Phase::Smoothness will be something like:
>
> Phase::VerySmooth
> Phase::Smooth
> Phase::Normal
> Phase::Fast
> Phase::Veryfast

some of these should be managed by the global computing context (e.g. 
powersave, as you note later) and the rest can be managed by adding more 
items to the enumerations.

> So, now there's the problem for the user of how to set an animator.
>
> Now, a KCM with two comboboxes would be the best thing for me to be able to
> configure the animators, makes the user choose one for when he's on AC, and
> one for when he's battery-powered. It should be accessible from the toolbox
> and systemsettings.

we need a plasma kcm anyways to do things like pick themes. so this can be a 
good place to start that beast.

> I would propose to ship with plasma 4 animators: fast, normal, fancy and
> powersave, the first three would be to adapt to several levels of CPU
> speedness, while the latter is for when we're running on batteries.

sounds good; we currently ship 2: DefaultAnimator ("normal") and Animator 
itself (which doesn't actually do animations; this is the "non-animated" 
options useful for things like networked systems)

it also occured to me the other day that the customAnimation timers should 
also flow through the Animator so that they can be modulated as well (e.g. in 
non-animated mode simply move immediately to progress = 1 and skip any other 
frames)

> Oh, another thing, I want to write an animator which bases on a proper
> physics model, with some small bouncness when moving items around (like

cool =)

-- 
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 Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080106/7cdcdecd/attachment.pgp