Migrate the Material Date pickers to M3.#118603
Migrate the Material Date pickers to M3.#118603darrenaustin wants to merge 1 commit intoflutter:masterfrom darrenaustin:m3_date_picker
Conversation
| "md.comp.date-picker.modal.range-selection.container.shape": "md.sys.shape.corner.none", | ||
| "md.comp.date-picker.modal.range-selection.date.in-range.focus.state-layer.color": "onPrimaryContainer", | ||
| "md.comp.date-picker.modal.range-selection.date.in-range.focus.state-layer.opcaity": "md.sys.state.focus.state-layer-opacity", | ||
| "md.comp.date-picker.modal.range-selection.date.in-range.focus.state-layer.opacity": "md.sys.state.focus.state-layer-opacity", |
|
|
||
| const Size _calendarPortraitDialogSize = Size(330.0, 518.0); | ||
| // The M3 sizes are coming from the tokens, but are hand coded, | ||
| // as the current token DB does not contain landscape versions. |
There was a problem hiding this comment.
Could you put these values into the template so that if they add the landscape versions we only need to change the template?
There was a problem hiding this comment.
I attempted this. Unfortunately only the portrait dialog dimensions, "md.comp.date-picker.modal.container{.width,height}" appear literally in the tokens data. The other four sizes used by date_picker.dart aren't given explicitly. Additionally: exposing these sizes in the date picker's theme would be difficult because so much of the layout depends on the overall size of each container. Loosening up the layout interdependencies to enable developers to customize the size of each dialog variation, might yield more complexity than it's worth.
So for now, I'd like to leave this internal size constants as they are.
There was a problem hiding this comment.
The way I handled this for the time picker was to have an intermediary abstract class for the defaults that had some local size values that could be used in the code, but weren't exposed in the public Theme API. For example, here. They could then be overridden for M2 and M3 variants.
The other advantage of that approach was that all of the properties can be changed to return non-nullable versions, so that none of the references in the code need to have a ! on them.
|
|
||
| Size _dialogSize(BuildContext context) { | ||
| final Orientation orientation = MediaQuery.orientationOf(context); | ||
| final bool useMaterial3 = Theme.of(context).useMaterial3; |
There was a problem hiding this comment.
Maybe move this into the switch statements, so that in the case where it's landscape, it doesn't need to set up an inheritance dependency on Theme? I mean, I know it's probably going to have one anyhow, but if we convert theme to an InheritedModel or something someday, that will be important.
| final TextTheme textTheme = theme.textTheme; | ||
| final DatePickerThemeData datePickerTheme = DatePickerTheme.of(context); | ||
| final DatePickerThemeData defaults = DatePickerTheme.defaults(context); | ||
| final bool useMaterial3 = Theme.of(context).useMaterial3; |
There was a problem hiding this comment.
You could move the Theme.of(context) to a local final theme variable to avoid looking it up three times.
| @@ -581,14 +597,24 @@ class _DatePickerDialogState extends State<DatePickerDialog> with RestorationMix | |||
| : localizations.datePickerHelpText.toUpperCase() | |||
There was a problem hiding this comment.
Use the new useMaterial3 variable here instead.
| /// The text style used for each individual day label in the grid of the | ||
| /// date picker. | ||
| /// | ||
| /// The color of the [dayStyle] is not used directly, as |
There was a problem hiding this comment.
Same comment here about it sounding deprecated.
| /// The text style used to paint each of the year entries in the year | ||
| /// selector of the date picker. | ||
| /// | ||
| /// The color of the [yearStyle] is not used directly, as |
There was a problem hiding this comment.
Same comment about deprecation.
| /// The color used for text labels and icons in the header of a full | ||
| /// screen [DateRangePickerDialog] | ||
| /// | ||
| /// This is used instead of any colors provided by |
There was a problem hiding this comment.
So why do those exist?
There was a problem hiding this comment.
This kind of issue comes up all of the time with compound visual style properties like BorderSide and TextStyle. The motive for setting up TextStyle properties with a separate text color property is two common cases:
- Use the default TextStyle but override the default text color. Don't make the user create a TextStyle that matches the default just to change the color.
- Override the default TextStyle but do not override the default text color. Similar to above and note that the default color for a TextTheme TextStyle is likely to be wrong.
| dayForegroundColor: dayForegroundColor ?? this.dayForegroundColor, | ||
| dayBackgroundColor: dayBackgroundColor ?? this.dayBackgroundColor, | ||
| dayOverlayColor: dayOverlayColor ?? this.dayOverlayColor, | ||
| todayForegroundColor: todayForegroundColor ?? this.todayForegroundColor, |
There was a problem hiding this comment.
What about todayBackgroundColor?
| @@ -239,9 +239,13 @@ class _InputDatePickerFormFieldState extends State<InputDatePickerFormField> { | |||
| Widget build(BuildContext context) { | |||
| final MaterialLocalizations localizations = MaterialLocalizations.of(context); | |||
| final InputDecorationTheme inputTheme = Theme.of(context).inputDecorationTheme; | |||
There was a problem hiding this comment.
You could separate out a theme final var here too.
|
This PR has been continued in a new PR: #119033 |
Part of: #91605
Updated the Date Pickers with support for Material Design 3.
In order to use the date pickers with the new Material 3 defaults, turn on the
useMaterial3flag in theThemeData:This PR includes a new
DatePickerThemethat can be used to configure the look of the components used in the date picker widgets (i.e.showDatePicker,showDateRangePicker,DatePickerDialog,DateRangePickerDialog,CalendarDatePicker, andInputDatePickerTextField.Fixes: #101481
Pre-launch Checklist
///).