Question on Qt animation framework

[Parker Coates]

On Fri, Aug 27, 2010 at 21:50, Hugo Pereira Da Costa wrote:
> 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 !

Keep in mind that if you're doing custom low-level animations you also
have to option of inheriting from QVariantAnimation or even
QAbstractAnimation directly. QPropertyAnimation is a pretty slick high
level API, but if you aren't dealing with high level QObject and
properties, it's sometimes simpler to roll your own QAbstractAnimation
subclass.

>> > 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.

Christoph is correct. Assuming that the animation isn't interupted,
you'll always get (at minimum) a valueChanged( endValue() ) signal.

Parker