I'm wondering if the native version is a rounded rect or a rounded superellipse (squircle). Can you attach images to the PR description comparing the native version?

I've tried to look at https://developer.apple.com/design/human-interface-guidelines/progress-indicators

and from the photo

it looks like rounded rect? But again, I half guessing here

The native photo attached has less-rounded corners on the edges than the flutter photo attached. But the actual blue line has the same rounding (I think) in both.

It's true on the picture it looks like the container has less rounded corners.

However, if I look at https://developer.apple.com/design/human-interface-guidelines/progress-indicators

it looks like the background AND the blue line are having a stadium shape, which is like the current implementation

Having said that, what would you prefer me to do?

I can replace the current native image attached to the PR description with the ones from https://developer.apple.com/design/human-interface-guidelines/progress-indicators

Can you attach images from a running native iOS app? The goal is to match live widgets, not HIG website photos.

Fair enough, I create a straightforward macOS app:

It looks like a stadium shape to me. What do you think?

Sounds good. If the native app is stadium-shaped then it should be stadium-shaped.

This part is not true for Cupertino

Sorry to belabor this, but can you explain why this is not true for cupertino again?

value is never null for CupertinoActivityIndicator.

For the animated/indeterminate version, value = 1. This value is used to calculate the number of "ticks" to display:

Here is a video, which I think makes it clearer:

Do you have a better way of handling progress and value?

No. But does this class and MaterialProgressIndicator need to be public? In general I'm thinking this project can be done without increasing the API surface anywhere (except maybe with getValueColor), what do you think?

Sure, makes sense! I've made CupertinoProgressIndicator and MaterialProgressIndicator private in Make _MaterialProgressIndicator and _CupertinoProgressIndicator private

Making them private means a bunch of documentation needs to be re-written for _MaterialProgressIndicator:

Knowing that, should I leave MaterialProgressIndicator public?
Or should I not reference it in the documentation?

I think you can reference the widgets themselves. Adding new public APIs should be done only when necessary, not just for documentation. This is because any later changes to that public API will be breaking.

I mean the widgets that extend the private classes, like LinearActivityIndicator etc. And where appropriate just use ProgressIndicator.

Got it! I updated the documentation in Update documentation, tell me what you think of it :)

Is that considered a breaking change? Is it acceptable?

Why can't progress be used here?

To share code with ProgressIndicator, I've made _CupertinoProgressIndicator this way:

  const _CupertinoProgressIndicator({
    super.key,
    double progress = 1,
    super.semanticsLabel,
    super.semanticsValue,
    this.color,
  }) : super(value: progress);

  @override
  double get value => super.value!;

So CupertinoActivityIndicator extends _CupertinoProgressIndicator no longer has the property progress, it has the property value

Do you prefer me to change the override of the getter value into

  double get progress => super.value!;

?

This is also technically a breaking change. What do you think about it?

Is this a breaking change? It seems to me that it is just introducing a new class between ProgressIndicator and LinearProgressIndicator.

If a user implemented class MyClass extends ProgressIndicator, this code will now break because Color getValueColor(BuildContext context, {Color? defaultColor}); is abstract now

But getValueColor was previously private. and I think ProgressIndicator can implement getValueColor so it is not abstract? Could return color ?? defaultColor.

I don't have any field color in ProgressIndicator. I felt like it was better to keep it in the Material and Cupertino implementations.

Would you prefer me to add color to the widget.ProgressIndicator class?

But getValueColor was previously private. and I think ProgressIndicator can implement getValueColor so it is not abstract? Could return color ?? defaultColor.

No. But does this class and MaterialProgressIndicator need to be public? In general I'm thinking this project can be done without increasing the API surface anywhere (except maybe with getValueColor), what do you think?

Why can't progress be used here?

Why is this logic in a new public mixin and not in ProgressIndicator itself?

Looking at the implementation of the different classes LinearProgressIndicator, CircularProgressIndicator, CupertinoActivityIndicator, they were implemented the same things:

  late AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(duration: duration, vsync: this);
    if (animating) {
      _controller.repeat();
    }
  }

  @override
  void didUpdateWidget(T oldWidget) {
    super.didUpdateWidget(oldWidget);
    if (widget.value == null && !_controller.isAnimating) {
      _controller.repeat();
    } else if (widget.value != null && _controller.isAnimating) {
      _controller.stop();
    }
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

Since you were suggesting to share as much code as possible in

#170108 (comment)

Basically we want to share as much code as possible between material and cupertino.

I took the initiative to share the same code for all the widgets. This is what I came up with
Would you prefer me to do it another way?

Is it possible to have this logic in ProgressIndicator itself? without needing to create a new public mixin.

This logic needs to be in a state of a widget (initState, dispose, didUpdateWidget, storing _controller), so it cannot be in ProgressIndicator.
Or maybe I misunderstood your suggestion?

I mean the widgets that extend the private classes, like LinearActivityIndicator etc. And where appropriate just use ProgressIndicator.

I think here and otherwise you can even revert the documentation changes entirely. After all, LinearProgressIndicator and the others are all ProgressIndicators.

Is it possible to have this logic in ProgressIndicator itself? without needing to create a new public mixin.

Sorry to belabor this, but can you explain why this is not true for cupertino again?