Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Migrate the Material Date pickers to M3. #118603

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

Closed
wants to merge 1 commit into from
Closed

Migrate the Material Date pickers to M3. #118603

wants to merge 1 commit into from

Conversation

darrenaustin
Copy link
Contributor

@darrenaustin darrenaustin commented Jan 17, 2023

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 useMaterial3 flag in the ThemeData:

  return MaterialApp(
    theme: ThemeData(useMaterial3: true),
    // ...
  );

This PR includes a new DatePickerTheme that can be used to configure the look of the components used in the date picker widgets (i.e. showDatePicker, showDateRangePicker, DatePickerDialog, DateRangePickerDialog, CalendarDatePicker, and InputDatePickerTextField.

Fixes: #101481

Pre-launch Checklist

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I read the [Tree Hygiene] wiki page, which explains my responsibilities.
  • I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
  • I signed the [CLA].
  • I listed at least one issue that this PR fixes in the description above.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is [test-exempt].
  • All existing and new tests are passing.

@flutter-dashboard flutter-dashboard bot added f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels. c: contributor-productivity Team-specific productivity, code health, technical debt. labels Jan 17, 2023
@@ -44,12 +44,12 @@
"md.comp.date-picker.modal.range-selection.container.elevation": "md.sys.elevation.level0",
"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",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

import 'scaffold.dart';
import 'text_button.dart';
import 'text_field.dart';
import 'text_theme.dart';
import 'theme.dart';

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you put these values into the template so that if they add the landscape versions we only need to change the template?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@gspencergoog gspencergoog Jan 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -426,20 +434,22 @@ class _DatePickerDialogState extends State<DatePickerDialog> with RestorationMix

Size _dialogSize(BuildContext context) {
final Orientation orientation = MediaQuery.orientationOf(context);
final bool useMaterial3 = Theme.of(context).useMaterial3;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final TextTheme textTheme = theme.textTheme;
final DatePickerThemeData datePickerTheme = DatePickerTheme.of(context);
final DatePickerThemeData defaults = DatePickerTheme.defaults(context);
final bool useMaterial3 = Theme.of(context).useMaterial3;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could move the Theme.of(context) to a local final theme variable to avoid looking it up three times.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 70d860d

@@ -581,14 +597,24 @@ class _DatePickerDialogState extends State<DatePickerDialog> with RestorationMix
: localizations.datePickerHelpText.toUpperCase()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the new useMaterial3 variable here instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 70d860d

/// 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here about it sounding deprecated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 024dad5

/// 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment about deprecation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 024dad5

/// 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So why do those exist?

Copy link
Contributor

@HansMuller HansMuller Jan 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about todayBackgroundColor?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch! Addressed in 024dad5

@@ -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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could separate out a theme final var here too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 70d860d

@HansMuller
Copy link
Contributor

This PR has been continued in a new PR: #119033

@HansMuller HansMuller closed this Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: contributor-productivity Team-specific productivity, code health, technical debt. f: material design flutter/packages/flutter/material repository. framework flutter/packages/flutter repository. See also f: labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update DatePicker to support Material 3
3 participants