Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change).

If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Changes reported for pull request #173108 at sha 9ec08fa

This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Golden file changes are available for triage from new commit, Click here to view.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Changes reported for pull request #173108 at sha 79465a7

Hi @QuncCccccc, thanks a lot for your review and suggestions! I added a number of comments to help understand the code. Could you please take a look again when you have time?

@QuncCccccc, I noticed that the Android material-components implementation of the progress indicator handles the effective trackGap differently. In that version, the trackGap gradually increases until progress reaches 1%, after which it remains at its full length (Source 1, Source 2).

Below is the comparison of the two approaches with a trackGap: 20. The top one is from the Compose (the one which is used in this PR), and the bottom one is from the Android material-components library.

The code for the new approach:

double getEffectiveTrackGapFraction(double currentValue, double trackGapFraction) {
  // If the progress is less than 1%, the gap will be proportional to the
  // progress. So that, it draws a full track at 0%.
  const double kGapRampDownThreshold = 0.01;

  return trackGapFraction *
      clampDouble(currentValue, 0, kGapRampDownThreshold) /
      kGapRampDownThreshold;
}

Given this difference in the effective trackGap calculation, should we align with the Android implementation, or use a Compose one?

I think both are fine. We can use the current algorithm as is because I think usually the gap is small and we can barely detect the difference during animation.

Update: I just talked with @TahaTesser who implemented the updated LinearProgressIndicator. Since overall the Android material-components repo are more reliable and usually have faster updates from newer Material specs, keeping the original calculation (material-components) would be a better option.

@QuncCccccc, sorry for the spam, I messed up a bit with git.

I updated the effective trackGap calculation to be exactly as in the Android material-components library. This will probably update the goldens again. Could you please give this PR another look?

Golden file changes are available for triage from new commit, Click here to view.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Changes reported for pull request #173108 at sha 639c579

Golden file changes are available for triage from new commit, Click here to view.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Changes reported for pull request #173108 at sha 777e414

@QuncCccccc thanks a lot for your review and suggestions!

@QuncCccccc I don't see Google Testing in checks, and not sure why it wasn't run after the master branch merge. Today morning, Google Testing was failing in this PR, so in case there are any issues with the tree, we need to revert this PR.

Oh thank for letting me know! For this kind of change, we probably should only submit it after Google testing has passed next time.

not sure why it wasn't run after the master branch merge.

Yeah, the google testing sometimes just don't start testing. Might need to try to re-trigger it by rebasing with master.