-
Notifications
You must be signed in to change notification settings - Fork 28.9k
Added a ProgressIndicatorTheme. #81075
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added a ProgressIndicatorTheme. #81075
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
packages/flutter/lib/src/material/progress_indicator_theme.dart
Outdated
Show resolved
Hide resolved
packages/flutter/lib/src/material/progress_indicator_theme.dart
Outdated
Show resolved
Hide resolved
packages/flutter/lib/src/material/progress_indicator_theme.dart
Outdated
Show resolved
Hide resolved
…rty to three different properties.
Thanks for the review. I have updated based on your comments. I have also broken out the Let me know what you think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have also broken out the backgroundColor theme property to linearTrackColor, circularTrackColor, and refreshBackgroundColor as they each interpret the background color in different ways with different defaults. An app might want to specify the track color of the linear progress bars and not have it change the background color of the refresh indicators. If they were one property there would be no easy way to have different behavior for each of the indicator types.
Let me know what you think.
Breaking out the properties that are roughly "background color" but actually mean something specific to the progress indicator subclass, makes sense to me. And I agree that theme users might want to just change the linearTrackColor. It might be clearer if the widget subclasses had the same constructor parameter name as the theme. So for LinearProgressIndicator: super(backgroundColor: linearTrackColor, ...)
etc.
/// also null then with the current theme's [ColorScheme.primary]. | ||
/// If null, the progress indicator is rendered with [color]. If that is null, | ||
/// then it will use the ambient [ProgressIndicatorThemeData.color]. If that | ||
/// is also null then it defaults to the current theme's [ColorScheme.primary]. | ||
/// | ||
/// This property is ignored if used in an adaptive constructor inside an iOS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, this warning, which is all over the place, just refers to CircularProgressIndicator.adaptive. Assuming that's true, we should just call out CircularProgressIndicator.adaptive specifically and eliminate this boilerplate comment where it's not really necessary. OK to do that in a separate PR BTW.
I had that at one point, but we would still need to support |
Adds a new
ProgressIndicatorTheme
to allow applications to theme the color properties of progress indicators in their apps. Follows the pattern for themes described in Theme System Updates.The following properties are supported by this theme:
New tests were added to verify that the theme values are used if specified.
Fixes: #77647
This PR was added per #56918.
Pre-launch Checklist
///
).