Themes Playground outputs incorrect colors for error and errorContainer

[frankpape]

Using the following settings in Themes Playground ("Example Midnight" palette selected, everything else is default):

{
    "playground_data": "Themes Playground data exported 18.01.2025 07:56:42",
    "playground_version": "8.1.0",
    "schemeIndex": 0,
    "topicIndexEndSide": 4
}

The Color Scheme tab shows that the error color should be set to 0xFFB00020, and onError should be 0xFFFFFFFF in light mode, however the generated code sets error and errorContainer to transparent (for both light and dark):

    error: Color(0x00000000),
    errorContainer: Color(0x00000000),

[rydmike]

Hi @frankpape, thanks for the report. Good find!

For this particular special case the Playground should actually not output any Color values for error and errorContainer and fall back to defaults from what the FlexColorScheme package. That is actually what the Playground does when it shows the error colors for this particular scheme. I will fix it so it does that.

The first three schemes in the Playground, are actually not a part of the built-in schemes in the FlexColorScheme package.

They are defined in Playground code, using FCS APIs and were originally added to demonstrate some different convenience APIs you can use to define input colors, by just giving a few color values instead of an entire ColorScheme or even all colors in FlexSchemeColor.

FCS was kind of using "seed" generated ColorSchemes before that was even a thing and Material-3 existed. Its computational color generation algorithms are a lot simpler than the more refined seed generation algos used in Material-3 and also in FlexColorScheme and Playground when enabling seed generated ColorScheme.

The first scheme in the Playground actually defines the scheme like this in the Playground code, so it is not included in FlexColorScheme packaged schemes:

  static const FlexSchemeColor _myScheme1Light = FlexSchemeColor(
    primary: Color(0xFF00296B),
    primaryContainer: Color(0xFFA0C2ED),
    primaryLightRef: Color(0xFF00296B),
    secondary: Color(0xFFD26900),
    secondaryContainer: Color(0xFFFFD270),
    secondaryLightRef: Color(0xFFD26900),
    tertiary: Color(0xFF5C5C95),
    tertiaryContainer: Color(0xFFC8DBF8),
    tertiaryLightRef: Color(0xFF5C5C95),
    // The built in schemes use their tertiary color as their default
    // custom app bar color, but it can be any color. We use a custom color
    // here. We will see this in example 5 when using the theme and selecting
    // the custom app bar style. We use a light blue that matches branded
    // surface colors, but is a bit stronger than most surface branding.
    appBarColor: Color(0xFFC8DCF8),
    swapOnMaterial3: true,
  );
// Create a corresponding custom flex scheme color for a dark theme.
  static const FlexSchemeColor _myScheme1Dark = FlexSchemeColor(
    primary: Color(0xFFB1CFF5),
    primaryContainer: Color(0xFF3873BA),
    primaryLightRef: Color(0xFF00296B),
    secondary: Color(0xFFFFD270),
    secondaryContainer: Color(0xFFD26900),
    secondaryLightRef: Color(0xFFD26900),
    tertiary: Color(0xFFC9CBFC),
    tertiaryContainer: Color(0xFF535393),
    tertiaryLightRef: Color(0xFF5C5C95),
    // A custom very dark blue, to match the dark theme mode
    appBarColor: Color(0xFF00102B),
    swapOnMaterial3: true,
  );

I will fix the output, and exclude outputting the error colors and it will produce the correct and same error colors via defaults when used. The effective result will then also as it is visually shown in the Playground. I verified this.

More background info and the 2nd and and 3rd themes in the Playground

I should also change the generated code for the 2nd and 3rd scheme too, and display the code that is actually used internally to generated shown colors.

What those two schemes do now is show the full FlexSchemeColor that the used APIs generate from their API config code. The end result for them are the same, but it does not actually in the Themes Playground teach and show the possibilities with the various FlexSchemeColor APIs and demonstrate what you can do with them.

The second scheme in the code contains this long text that is use in the tutorial docs, that were more used before the Playground automated using the API and nobody has to configure it by hand anymore:

  // We can build a scheme the long way, by specifying all the required
  // scheme colors, like above, or we can also build schemes from a single
  // primary color. With the `FlexSchemeColor.from` factory. When doing so the
  // only required color is the primary color, the other colors will be
  // computed. We can optionally also provide the `primaryContainer`,
  // `secondary` and `secondaryContainer` colors with the factory, but any
  // color that is not provided will always be computed to get all the required
  // colors in a `FlexSchemeColor`.

  // In this example we create our 2nd scheme from just a primary color for the
  // light and dark schemes. The custom `appBarColor` does in this case also
  // receive the same color value as the one that is computed for
  // `secondaryContainer` color. This is its default with the
  // `FlexSchemeColor.from` factory if the color is not specified.

  // The `brightness` parameter in the `FlexSchemeColor.from` factory is new
  // in version 5. If `brightness` is specified the factory computes missing
  // colors that are well suited for a Material 3 based ColorScheme, of the
  // given brightness. If brightness is not specified, then the algorithm is
  // same as before version 5, but with two more colors. Its produced colors
  // fit better for M2 specification, they do also work in M3, they just don't
  // follow the guidelines with respect to the hue of the main color and its
  // container pair color. When using the `FlexSchemeColor.from` with
  // Material 3 `ColorScheme`, prefer specifying the brightness value for
  // results following the Material 3 design intent.
  static final FlexSchemeColor _myScheme2Light = FlexSchemeColor.from(
    primary: const Color(0xFF065808),
    brightness: Brightness.light,
  );
  static final FlexSchemeColor _myScheme2Dark = FlexSchemeColor.from(
    primary: const Color(0xFF629F80),
    primaryLightRef: _myScheme2Light.primary,
    secondaryLightRef: _myScheme2Light.secondary,
    tertiaryLightRef: _myScheme2Light.tertiary,
    brightness: Brightness.dark,
  );

The 3rd scheme is actually made with even less input, by just defining a few light mode colors:

  // For our 3rd custom scheme we will define primary and secondary colors, but
  // no container colors, we will not make any dark scheme definitions either.
  // All these missing colors will be computed, the missing color definitions
  // will get computed by the factory `FlexSchemeColor.from` when it creates the
  // `FlexSchemeColor` object. To make our dark colors for this light scheme, we
  // use the method `toDark` further below with the `_myScheme3Light` instance.
  static final FlexSchemeColor _myScheme3Light = FlexSchemeColor.from(
    primary: const Color(0xFF1145A4),
    secondary: const Color(0xFFB61D1D),
    brightness: Brightness.light,
    swapOnMaterial3: true,
  );

and the dark mode for this is done with a one liner:

      // We create the dark desaturated colors from the light scheme.
      // The `swapColors` parameter is `true` here. It is new in version 5. It
      // swaps main and container colors values for the primary its container,
      // likewise for secondary and tertiary and their containers.
      //
      // This is done because in Material 3 light mode, the main color should
      // be darker or more saturated than the container, but in dark mode it
      // should be the other way around. By setting the flag to true, this is
      // done before the light theme mode colors are reused as dark theme and
      // desaturated using `whiteBlend` level value.
      dark: _myScheme3Light.defaultError.toDark(30, true),

Yeah, I should definitely update what the Playground outputs for the 2nd and 3rd custom schemes too. Basically handle them all as special cases to generate the actual code that is used to generate the shown schemes. I'll add a short comment the generated code to explain the 3 special cases as well.

Fix in what release?

I will probably not land this fix until I release version 8.2.0.

Until then, for this particular case in the Playground, just delete the generated code lines with error and errorContainer for both light and dark mode, to get the same result and effective colors as the ones shown in the Playground, when you use the generated code.

Issue scope

This issue only concerns the Playground and the code it generates, not the actual FlexColorScheme package, but it should of course be correct. Good find, thank you!

[rydmike]

A fix for this particular case has been committed to the 8.2.0 development branch. I will keep this issue open until the fixed has been merged into master and a new version of the Playground has been published.