Version 3.4.0

3.4.0

Sep 23, 2024

CHANGE

• The parameter useExpressiveOnContainerColors in SeedColorScheme.fromSeeds now works with a scheme variant regardless of if it has isFlutterScheme set to true or false. Meaning it impacts both MCU DynamicSchemeVariant and FSS FlexTones based scheme variants.

  • For FlexTones based variants, when using a built-in FlexTones or even a custom one, it is no longer necessary to use the FlexTones modifier .expressiveOnContainer() on the used tones to get a seeded color scheme with expressive on container tones in light mode.
  • The FlexTones based modifier .expressiveOnContainer() is still used, but it is applied internally when the flag useExpressiveOnContainerColors is set to true.
  • The useExpressiveOnContainerColors only applies in light mode to on container tones that are equal to 10, other tones are considered custom on purpose and are not changed. This is in-line with that the MCU DynamicSchemeVariants that did not use tone 30 before as on container color in light mode, like Fidelity, Monochrome and Content were not affected by this change in MCU 0.12.0. In the same manner, this flag no longer changes FlexTones based schemes that have on container tones that are not 10. This applies to some on container colors in UltraContrast, Candy Pop and Chroma predefined FlexTones.
  • This change makes this flag consistent and applicable to all seed generated schemes, regardless of if it is based on DynamicSchemeVariant, built-in FlexTones or even custom FlexTones configurations.
  • For MCU seed generated schemes, useExpressiveOnContainerColors only has any impact when contrast level is at the default value (0), normal contrast.
  • When using FFS seed generated schemes with useExpressiveOnContainerColors set to true, the modifier is applied before any FlexTones modifiers. Using tones modifiers, like e.g. onMainsUseBW() will thus as expected, override this setting and set on container colors to tone 0 or tone 100, depending on the container colors brightness.

NEW

• A new bool parameter, respectMonochromeSeed in SeedColorScheme.fromSeeds can now be used to make seed generated ColorSchemes that work as expected if a monochrome color is used as seed color input.
  • When set to true, any monochrome RGB input value will result in the creation of a greyscale tonal palette for the palette using the monochrome seed color. An RGB monochrome value is one where Red, Green and Blue values are all equal.
  • Previously in FSS and in Material Color Utilities (MCU) and thus still as default in Flutter ColorScheme.fromSeed, using a monochrome seed color value or white, resulted in a tonal palette with cyan color tones. A black input resulted in red like color tones. This is not very intuitive and not really expected when using monochrome seed colors.
  • FSS still defaults to setting respectMonochromeSeed to false, to not break any existing code that may rely on the old behavior.
  • Prefer setting respectMonochromeSeed to true, to get more logical seed results when using monochrome seed colors or white and black as seed colors.
  • NOTE: When using respectMonochromeSeed with DynamicSchemeVariant variants fidelity or content, for some monochrome input colors they produce primaryContainer and onPrimaryContainer as well as tertiaryContainer and onTertiaryContainer color pairs, with low contrast. Consider using some other scheme variants with monochrome seed colors. All others work well with any monochrome seed color. This is just how the MCU DynamicSchemes SchemeContent and SchemeFidelity are defined in MCU. They also produce fairly low contrast for these color pairs with very dark seed colors. This behavior with MCU's SchemeContent and SchemeFidelity could be fixed in FlexSeedScheme's internal MCU fork, but we want to keep the result of these schemes consistent with MCU.