question about dynamic color

[fredgrott]

Hello Mike,

So working through implementing dynamic color using FCS. From what I gather is that I could create a custom dynamic color builder that still uses the dynamic color package to get the corePalette generated from user set color and then have that builder return a light and dark ThemeData via the FlexColorScheme.light or dark toTheme setup.

Or is there a better solution? Does seem like a bad solution as I would only have to do copyWith on FlexSchemeColor with the generated corePalette stuff and then keep brightness and appBarColor the app defaults.

Thoughts?

[rydmike]

Hi Fred,

If you are using this method to get dynamic color, harmonized or not, and tweaked with own colors or not:

https://github.com/material-foundation/material-dynamic-color-flutter/blob/main/example/lib/complete_example.dart

You still end up with two standard ColorSchemes, one for light and one for dark mode. Simply
pass the light one to FlexThemeData.light(colorScheme: dynamicLight) (or FlexColorScheme.light if using the factory that gives you the FlexColorScheme object first). Ditto for dark version.

FlexColorScheme will then use this ColorScheme as its input colors. You can still configure all other FlexColorScheme props, sub-themes, and even blends, to further modify surface colors in the input ColorScheme. To keep the surface blends as give by the M3 dynamic theme, just keep blends to 0.

So you can thus even use the themes playground to set everything else as you want and just put in the dynamic schemes to its colorScheme property, it will override any color definitions, via default

Going further you could have toggles in your app that use a ThemeData made with dynamic scheme and or built in ones or custom colors, all output as ThemeData via FCS.

I have been planning to add an example on how to use FCS with dynamic color, but have not gotten around to it yet 😄

Hope this helps! Let me know if it does, I might convert this issue into a QA in the repo Discussions.

br Mike

More reading below:

From the FlexThemeData.light extension and FlexColorScheme.light factory docs:

    /// The [FlexSchemeColor] that will be used to create the light
    /// [FlexColorScheme].
    ///
    /// You can use predefined [FlexSchemeColor] values from [FlexColor] or
    /// [FlexColor.schemes] map or define your own colors with
    /// [FlexSchemeColor] or [FlexSchemeColor.from].
    ///
    /// For using built-in color schemes, the convenience shortcut to select
    /// it with the [scheme] property is recommended and leaving [colors]
    /// undefined. If both are specified the scheme colors defined by [colors]
    /// are used. If both are null then [scheme] defaults to
    /// [FlexScheme.material], thus defining the resulting scheme.
    final FlexSchemeColor? colors,

    /// Use one of the built-in color schemes defined by enum [FlexScheme].
    ///
    /// Give it one of the enum values to use the scheme, like eg.
    /// [FlexScheme.mandyRed].
    ///
    /// To create custom color schemes use the [colors] property. If both
    /// [colors] and [scheme] are specified, the scheme defined by
    /// [colors] is used. If both are null, then [scheme] defaults to
    /// [FlexScheme.material].
    final FlexScheme? scheme,

    /// The overall [ColorScheme] based colors for the theme.
    ///
    /// This property provides a new way to define custom colors for
    /// [FlexColorScheme] and is available from version 4.2.0. It is useful if
    /// you already have a custom [ColorScheme] based color definition that
    /// you want to use with FlexColorScheme theming and its sub-theming
    /// capabilities.
    ///
    /// If you provide both a [ColorScheme] and some individual direct property
    /// values that also exist in a [ColorScheme], the individual property
    /// values will override the corresponding ones in your [ColorScheme].
    ///
    /// If you do not define a [colorScheme], the used colors will be determined
    /// by the [colors] and [scheme] properties. However, when a [colorScheme]
    /// is defined it takes precedence. The [brightness] in the provided
    /// [colorScheme] is always ignored and set to [Brightness.light] since this
    /// is the light theme mode factory. Make sure the colors used in your color
    /// scheme are intended for a light theme.
    ///
    /// If you define a [surfaceMode] and set [blendLevel] > 0, then [surface]
    /// and [background] colors in the provided [colorScheme] will be overridden
    /// by the computed color branded surfaces. If your [colorScheme] already
    /// contains branded surface colors, then keep [blendLevel] = 0 to continue
    /// using them.
    ///
    /// If you use [lightIsWhite] factory feature, it will also override your
    /// [colorScheme] based [surface] and [background] properties and make them
    /// 8% lighter.
    ///
    /// If you opt in on using sub themes with [useSubThemes] and have set
    /// [subThemesData.blendOnColors] to true and have defined [surfaceMode]
    /// and set [blendLevel] > 0, then the effective color scheme based on
    /// colors onPrimary, onSecondary, onError, onSurface and onBackground will
    /// be changed accordingly too.
    ///
    /// The [colorScheme] colors are also included and affected by factory
    /// properties [usedColors] and [swapColors] and included in their behavior.
    ///
    /// The [FlexColorScheme]'s effective [ColorScheme] can be returned with
    /// [toScheme]. This will always get you a complete color scheme, including
    /// calculated and derived color values, which is particularly useful when
    /// using the [FlexColorScheme.light] and [FlexColorScheme.dark] factories
    /// to compute color scheme branded surface colors for you. The effective
    /// [ColorScheme] for your theme is often needed if you want to create
    /// custom sub-themes that should use the colors from the scheme using none
    /// default color assignments from the color scheme.
    final ColorScheme? colorScheme,