Question on Qt animation framework

[Hugo Pereira Da Costa]

On Friday 27 August 2010 19:40:31 Christoph Feck wrote:
> On Saturday 28 August 2010 03:11:27 Hugo Pereira Da Costa wrote:
> > Hi all,
> > I have a technical question concerning animations.
> 
> Not exactly KDE related, but I will answer anyway :)
> 
> > All over the place in oxygen QPropertyAnimations trigger updates of
> > widgets with a slot/signal call a la:
> > 
> > connect(
> > 
> >   animation, SIGNAL( valueChanged( const QVariant& ) ),
> >   widget, SLOT( update( void ) ) );
> 
> This is not how QPropertyAnimation is supposed to work. When you animate a
> property, lets say "opacity", then QPropertyAnimation internally calls
> "setOpacity" on the widget during the animation. Inside the "setOpacity"
> function, you compare the old and the new opacity, and when it changed, you
> call update() in that function.
> 
> There is no need to connect anything when using the QPropertyAnimation.


mmm. Your right. Except that I did not start with such an implementation 
(since originally I used QTimeLine, for which the above could not really be 
done). I guess it would need quite some serious rewrite of the oxygen 
animations, but I'm in a rewrite mood anyway. Thanks for reminding me ! 


> 
> > Now, I also added:
> > 
> > connect(
> > 
> > 	animation, SIGNAL( finished( void ) ),
> > 	widget, SLOT( update( void ) ) );
> > 
> > The question is: does anyone know whether the second call necessary or
> > superfluous, or in otherr words, when an animation runs, is it certified
> > that it will always call a valueChanged signal with its endValue() before
> > finishing.
> 
> If Qt does not do this, file a bug. It should even emit a single
> valueChanged() with the endValue at an animation of duration 0.

ok. I guess I'll give it a shot.

Thx! 

> 
> > I guess I can test it, but in case anyone knows that on top of his/her
> > mind, that would spare me some nasty QDebug
> > 
> > Thanks in advance,
> > 
> > Hugo