Add StrokeCap to CircularProgressIndicator - #122664

Since StrokeCap.round is only relevant to CircularProgressIndicator (If the Linear one chooses a radius instead), should this only be on the CircularProgressIndicator class?

I am also not sure if the name is clear as a user, why not use StrokeCap directly?

StrokeCap has 3 values and only 2 of them are relevant. Butt and Square collide with each other, because Circular uses Butt when it has value, Square when it doesn't (it is spinning).

should this only be on the CircularProgressIndicator

Probably. How do you think the theme should be? CircularHasRoundIndicator and LinearIndicatorRadius?

Renamed to preferRoundIndicator.

only 2 of them are relevant

I disagree with this statement, why are there 3 then? :) It's not for us to decide that one is irrelevant, the uses cases have been pointed out in the discussion of this PR.

How do you think the theme should be? CircularHasRoundIndicator and LinearIndicatorRadius?

Are there not individual component themes for circular and linear? I would not put both in the super class ProgressIndicatorTheme.

I disagree with this statement, why are there 3 then? :) It's not for us to decide that one is irrelevant, the uses cases have been pointed out in the discussion of this PR.

If it is square, the value is represented wrong: #109137 (comment).
If it is butt, it is represented correctly.

But if it is butt, on indeterminate, it "disappears", so whoever implemented it made it square so it is always visible.

Exposing this to the user is hard: on square they will have the wrong value, on butt they will have an "unintended" animation (which, if it is to be customizable, we could allow changing other things, such as speed).

Are there not individual component themes for circular and linear?

No, I could make one, I guess..

No, I could make one, I guess..

Oh, I meant that if they don't exist then we should probably omit theming support for now. :) No worries, no need to create more themes right now for this change.

This is a non-nullable parameter. How does it default to null? :)

ooops :P

Actually, I was playing with a few things and forgot to update the documentation. I was checking if I could "auto add a borderRadius" but my idea was bad and it is better to allow the user to break things. IndicatorBorderRadius = 100 + background = 0 result in a weird scenario I was trying to avoid, but I'm letting the user decide.

square or round

The name/boolean/square-round is kind of confusing here.

I think StrokeCap is still just the straightforward solution.

The issue with strokeCap, as I tried to explain before, is that butt/square are always wrong. If you want butt, indeterminate is wrong. If you want square, value is wrong.

There is no reason for square + value. That must be overridden.
There is no reason for butt + indeterminate. That must be overridden.

Would we have a fourth value (null?) that goes between butt and square? I think that's too much complexity for the user. Even introducing a new enum could be easier to understand.

enum CircularProgressIndicatorShape { square, round }

Is StrokeCap not properly documented? Again, these are decisions I do not think are fair for us to make for the developer. I think this should be StrokeCap.

How do you see the API working? Because either value (square/butt) would be breaking. The strokeCap is documented, but there is a hole from "square paints a bit more" to "it is going to paint the wrong progress value", which is what people won't want. It is hard to even find a default value, because the default depends on the state. Right now it mixes the two.

       | indeterminate | value |
butt   |      ❌       |   ✅   |
square |      ✅       |   ❌   |
round  |      ✅       |   ✅   |

How would it be breaking? Does exposing this value to developers break the default behavior?

Oh, I totally agree. The weird thing for me is that there would be 4 values and only 2 would be really "correct". So even though we want to give users options they will shoot themselves with 2 of them (which seem the correct thing, you have circle, you want... square, bang). But considering one day they might add other strokeCap effects, it makes sense.

I think where we are disagreeing here is that I do not feel we can be the arbiters of "correct" as you have been asserting. It could very well be the behavior the developer wants.

If the progress value starts on -10 instead of 0, we have a "deterministic" problem. No one would want it to start before, and if they want, we could just expose that number. Same thing, if they want value: 40, they don't want value: 50 (else we would expose like an offset and let they play with it).

For indeterminate, it is less bad because the material animation would change (most of them wouldn't notice), so I believe, if we want the material animation to be customizable, there are other ways of doing this (like allowing to change the speed, curves and delay).

I had a hard time, for example, in the LinearProgressIndicator to see if my borderRadius was working with indeterminate because it is too fast, what if I wanted slower? I can't set this. This could be more useful than say, a value that starts before and ends after.

Just my 2cts, I think it is fair to assume that a determinate CircularIndicator is "correct" if it starts right at 90 degrees and that it draws half of a circle when its value is 0.5. Both are not true when using StrokeCap.square (not to say it is not 'circular' because ‘StrokeCap.square’ really means there are two squares drawn at both ends of the arc, which might makes sense if you want to ‘connect’ lines and arcs).

Nonetheless, @Pinks point about the versatility of the public API is valid, especially considering @bernaferrari following argument: “one day they might add other strokeCap effects, it makes sense.” (maybe Impeller will).

I doubt so because CSS is 20 years old and only supports the same 3 strokeCap. But I agree they could. I just don't know what it could be that would add benefit to the framework.