Microsoft-ui-xaml: Progress Ring thickness inconsistency

[mdtauk]

Describe the bug
The Indeterminate ProgressRing does not scale in the same way as the Determinate one...

Steps to reproduce the bug
Change the size of the Progress Ring, and switch between Determinate and Indeterminate states

Expected behavior
Ring thickness should be consistent between states

Screenshots

This is width set to 90

Additional context
Due to the use of a Lottie animation for the Indeterminate animation, it may not be possible to adjust the stroke/ring thickness in real time.

[ranjeshj]

@mdtauk It should be possible to expose this. @karenbtlai was prototyping this I believe.

[mdtauk]

@mdtauk It should be possible to expose this. @karenbtlai was prototyping this I believe.

I know at present the colour of the progress segment is set by the framework. If there was a way to also set the thickness of the Ellipse shapes in code, and perhaps any of the other properties that XAML is able to set on the control - then that will make things perfect!

[karenbtlai]

@mdtauk I am still working with the Lottie Codegen team to refine the output so that StrokeThickness is settable. The goal is for it to also be consistent among both Determinate and Indeterminate states. What other properties specifically would you wish to see?

You can find the WIP here.

[mdtauk]

@karenbtlai Good to know its being worked on!

As for other properties... Can gradients be set as colours? And Opacity for the colours? Does CornerRadius apply in this case? Ellipse geometry can change the stroke end caps, but that is limited to round, flat, and dashed I think.

[karenbtlai]

@karenbtlai Good to know its being worked on!

As for other properties... Can gradients be set as colours? And Opacity for the colours? Does CornerRadius apply in this case? Ellipse geometry can change the stroke end caps, but that is limited to round, flat, and dashed I think.

@mdtauk In the current implementation, it only takes in SolidColorBrushes and converts it into ARGB for Lottie's Composition animations.

@YuliKl Perhaps these customization can be added on the list of to do?

[mdtauk]

I don't have specific use cases in mind, so can't be specific.

I think what I am hoping to do is promote the discussion about trying to keep the control as flexible for developers, as if it were entirely done in XAML.

Lottie did have a problem with gradients, but I think this is something that was recently overcome.

[Felix-Dev]

Tagging @robloo as they raised many such concerns in the Progress ring Lottie animation update PR: https://github.com/microsoft/microsoft-ui-xaml/pull/1858

[...] trying to keep the control as flexible for developers, as if it were entirely done in XAML.

[robloo]

@Felix-Dev This is new territory for sure and I'm curious to see how things progress, no pun intended. The Lottie animations are filling some gaps in the classic XAML storyboarding tech for sure. However, it's also introducing a whole new concept and an associated bag of worms. Issue reports like this really bring a big concern about future direction. Why are we adding all of these special-purpose properties for Styling? It's not the XAML way and it's certainly not robust long term especially if this type of thinking creeps into other controls.

I honestly feel if it was anyone but Microsoft making this patch it would be rejected from the repo for violating XAML conventions. Yet here we are. The compromise I was/am OK with in the short term is keeping it possible for the Lottie animation to be entirely swapped out (#1170) -- however that needs work #1968. I have a hope this eventually develops into something generic and fits nicely with XAML.

However, if Microsoft adds a property for every little thing like this it's going to get ugly real quick. It's also not something that can be removed in the future either as Microsoft has stated they won't be making significant API breaking changes like this. This isn't what XAML is supposed to be at all @StephenLPeters @ranjeshj. I feel like engineering is making sacrifices they shouldn't be making for the sake of design. Storyboard animations instead should be extended.

[mdtauk]

@robloo It is not adding properties to accommodate the Lottie Player, but mapping existing XAML properties to the code generated by the Lottie Exporter in After Effects

[robloo]

@mdtauk Ah ok, I misunderstand then. That said, I thought you were talking about exposing the ellipse stroke thickness (among others). What would this map to in the standard Control XAML styling properties like BorderBrush or BorderThickness? StrokeThickness is only used on primitives Shape classes usually for drawing in a canvas or similar.

Edit: Never mind, I realize you just are talking about making stroke thickness modifiable by C++ code behind so it could be consistent between states. It would never be exposed publicly for users of the ProgressRing.

[mdtauk]

@mdtauk Ah ok, I misunderstand then. That said, I thought you were talking about exposing the ellipse stroke thickness (among others). What would this map to in the standard Control XAML styling properties like BorderBrush or BorderThickness? StrokeThickness is only used on primitives Shape classes usually for drawing in a canvas or similar.

The Thickness is XAML controlled for the Determinate state, but when it is switched to Indeterminate, the Lottie player takes over.

I think the plan is for the Lottie animation code, to take its values from the XAML eventually.

[Felix-Dev]

It was my understanding that @mdtauk and @karenbtlai were discussing about mapping XAML control properties to the Lottie output so that they will be reflected in the final look (i.e. background/foreground, corner radius for the progress segment, thickness,...basically the XAML properties we grew accustomed to controls are exposing for us to change the look). Hence why I thought this would be of interest to @robloo too. If there was a missunderstanding caused by this I apologize!

[robloo]

@Felix-Dev This was my misunderstanding. I am curious to see how things go with animations like this and appreciate the heads up.