Proposal: Customizing ProgressRing, Markup friendly animated visual player

[ranjeshj]

Here are the different ways one could approach customizing the ProgressRing control.

1. Changing the colors (foreground, background)
2. Updating the animation
3. Changing the template (including updating the animations)

(1) is currently achieved through exposing properties on the ProgressRing for the app developer to change/bind to. I can imagine this to be a relatively common scenario and should not require re-templating.

(2) is less common and with the current implementation it is not straigtforwad to achieve this due to the nature of lottie/animated visual player. It is possible to switch over the template to achieve this and use storyboard animations or write more code to make custom lottie animatons work. See discussion here

(3) This is currently possible to do with storyboards but harder than it could be. I think the primary complexity is because lottie animations/animated visual player do not have the correct dependency properties to make it markup friendly. I would not recommend re-templating in most cases and use it as the very last resort, since re-templating is essentially a fork in the code and updates to the library will not be reflected in the app and any fixes to the default template will be missed. If we can expose certain properties on the control that will avoid re-templating, we should consider that first. That said, as a framework we do want to allow developers to make that decision.

These are the proposed changes that will help get us a better markup friendly way to expose animated visual player and lottie animations.

1. IsPlaying {get;set;} dependency property on AnimatedVisualPlayer to start/stop playing.
2. IsLooping {get;set;} dependency property on AnimatedVisualPlayer to enable looping the content.
3. Lottie gen generated type needs to expose the properties for background/foreground that are bindable.

With these changes, it should be possible to decouple the control logic from the animation code enabling the ability to provide custom lottie animations and re-template.The control code can just set template setting properties for the determinate ring to bind for the progress arc and have logic to go to the correct visual states (Determinate/Indeterminate). The rest can be triggered from the visual states.

I expect a template similar to below should be possible with these changes.

                <ControlTemplate TargetType="local:ProgressRing">
                    <Grid x:Name="LayoutRoot">
                        <VisualStateManager.VisualStateGroups>
                            <VisualStateGroup x:Name="CommonStates">
                                <VisualState x:Name="Normal" />
                                <VisualState x:Name="Determinate" />
                                <VisualState x:Name="Indeterminate">
                                   .. toggle visibility of animated visual player ..
                                   .. start animation .. 
                                </>   
                            </VisualStateGroup>
                        </VisualStateManager.VisualStateGroups>

                        <!-- paths for determinate visuals --> 

                        <!-- Indeterminate using lottie animations -->
                        <local:AnimatedVisualPlayer x:Name="LottiePlayer" AutoPlay="false" IsLooping="true">
                           <local:AnimatedVisualPlayer.Source>
                              <local:ProgressRingLoading Background={TemplateBind Background} .. />
                           </>
                        </>

                      ...
                </ControlTemplate>

[JohnnyWestlake]

An unfortunate side effect of using Lottie here is you only supported SolidColorBrush for foreground rather than any Brush (gradient, XAMLComposition, etc) that practically every other control in the framework supports for their brush properties. Seems like a strange little quirk to throw in for a new control.

[mdtauk]

An unfortunate side effect of using Lottie here is you only supported SolidColorBrush for foreground rather than any Brush (gradient, XAMLComposition, etc) that practically every other control in the framework supports for their brush properties. Seems like a strange little quirk to throw in for a new control.

Something like this should be documented

[robloo]

An unfortunate side effect of using Lottie here is you only supported SolidColorBrush for foreground rather than any Brush (gradient, XAMLComposition, etc) that practically every other control in the framework supports for their brush properties. Seems like a strange little quirk to throw in for a new control.

Something like this should be documented

I think that that shouldn't be document but fixed long term.