Investigate options for supporting different animations for target vs non-target items

ListView and GridView need to enable different animations for target items (i.e. the items being added/moved/removed) vs the items that are displaced as a result of the add/move/remove operation.

Options include:

• Providing add/move/remove transition-type properties on the view (like in Grid, Row, and Column), where each transition can access the target items and non-target items for the transition, and assign them as the "targets" for different animations
• Provide different properties on the view for each transition - e.g. 'move' and 'moveTargets'
• Provide the above properties as attached properties on the delegate instead of the view (unlikely to take this option since the view must create transitions for every item instead of reusing them)

To enable transitions that can be customised according to the item and the view operation, the Transition could have an attached or context property that provides:

• a list of the target items
• a list of the non-target items
• the index of the item that is currently being added/moved/removed

For example, the following specifies a transition for the Add operation. The target items (the items that are being added) will be animated from (100,100) to their correct position within the view. Other items (the items displaced by the add operation) will be animated to their new positions will a custom delay depending on their distance from the first target item.

    add: Transition {
        // delayed animations depending on index
        SequentialAnimation {
            PauseAnimation { duration: Math.abs(ViewTransition.index - ViewTransition.targetItems[0].index) * 200 }
            NumberAnimation { targets: ViewTransition.nonTargetItems; properties: "x,y" }
        }

        // different animation for the target items
        NumberAnimation { properties: "x,y"; target: ViewTransition.targetItems }
    }

If the above was made to work, the view would need to run a transition instance with different properties for each item that requires the transition. With the current architecture, this would require a new Transition instance for each item, which is expensive. However it may be possible to modify the internal animation architecture so that the Transition internally creates new instances of animations, rather than the view creating multiple instances of Transitions, which would be less expensive.

If we were to avoid creating one Transition instance per item within the current animation architecture, we could allow a single Transition for the view as below, by using some sort of animation repeater element that creates multiple animation objects for target and non-target items:

    add: Transition {
        NumberAnimation { properties: "x,y"; target: ViewTransition.targetItems }

        AnimationRepeater {
            model: ViewTransition.nonTargetItems
            PauseAnimation { duration: Math.abs(model.index - ViewTransition.targetItems[0].index) * 200 }
            NumberAnimation { properties: "x,y"; target: model.data }
        }
    }

This would be less expensive than one-transition-per-item, but more expensive than the scenario where the internal animation architecture is modified to enable multiple internal instances of animations rather than multiple Transition instances.