Extend QskAnimator to support advance callback

[rick-vogel]

WHAT

As a developer I want to define a functor / lambda for the actual advance of an animator

WHY

Otherwise I need to implement a custom animator and bring my context into this class

HOW

Maybe provide a setter allowing to define an advance handler callback. This would e.g. allow capturing the callback's context.

{
    QskAnimator animator;
    animator.setAdvanceCallback([button](qreal x){
          button.setX(value);
    })
}

SUGGESTION

class QskAnimator
{
public:
    void advance( qreal value ) override
    {
        m_callback( value );
    }

    void setAdvanceCallback( const std::function< void( qreal ) >& callback )
    {
        m_callback = callback;
    }

private:
    std::function< void( qreal ) > m_callback = []( qreal ) {};
};

[uwerat]

One could argue that any type of overloading should be replaced by using functors for the mentioned reasons. And for the specific suggestion you would also need functors for the setup and done methods of QskAnimator !

But following your suggestion it probably would have to be something like this:

class QskFunctorAnimator : public QskAnimator
{
    void advance( qreal value ) override final
    {
        m_callback( value );
    }

    void setCallback( const std::function< void( qreal ) >& callback )
    {
        m_callback = callback;
    }
private:
    std::function< void( qreal ) > m_callback = []( qreal ) {};
};

Note that value is the progress of the animation - something between 0.0 and 1.0 - and not a coordinate. So for the given example of the X coordinate of a button you would need additional start and end positions to calculate the current position. Furthermore you might need 4 animators for x/y/width/height. That soon leads to something like QPropertyAnimation, where a property ( QVariant ) gets interpolated driven by the Qsk animation system.

The vast majority of the animations using the QSkinny animations framework ( there are also the Qt animations ! ) are related to skin-state changes and are not initialized by application code. Most derived QskAnimators you find in the code of the specific controls are related to geometry, transformation, transparency, clipping manipulations and we should have Qsk support classes so that the code does not need to be duplicated in the implementation of the various controls.

So all in all I do not see many use cases for QskFunctorAnimator or QskPropertyAnimator classes today - but maybe we will find them later ...

[peter-ha]

Just some thoughts from our customer project:

We are using a class like QskFunctorAnimator above a lot internally, since we use different animators when opening pages etc. When subclassing QskAnimator for each of these animations, there is some boilerplate code needed. The actual body of the advance() method itself is often just one line, e.g. setting opacity or scale; in comparison to that the amount of boilerplate code seemed quite high. With a functor one could just create an animator instance and set the desired lambda, without needing to subclass...