Different colors when using Theme.of(context).colorScheme to access the theme colors (Seed input colors are not in produced theme.colorScheme, how to include them?)

[Errechydy]

I want to use the theme colors as background for some Containers but i couldn't get the right colors, for example in the code below the secondary color specified in the theme is red, but when i try to get it using Theme.of(context).colorScheme.secondary i get grey-ish color instead of red.

I'm using the latest version of the package
This code shows the issue:

import 'package:flutter/material.dart';
import 'package:flex_color_scheme/flex_color_scheme.dart';

void main() async {
  runApp(
    MaterialApp(
      debugShowCheckedModeBanner: false,
      theme: FlexThemeData.light(
        colors: const FlexSchemeColor(
          primary: Color(0xff1145a4),
          primaryContainer: Color(0xff9fb4da),
          secondary: Color(0xffb61d1d),
          secondaryContainer: Color(0xffe1a4a4),
          tertiary: Color(0xff376bca),
          tertiaryContainer: Color(0xffcfdbf2),
          appBarColor: Color(0xffcfdbf2),
          error: Color(0xffb00020),
        ),
        surfaceMode: FlexSurfaceMode.highScaffoldLowSurface,
        blendLevel: 20,
        appBarOpacity: 0.95,
        subThemesData: const FlexSubThemesData(
          blendOnLevel: 20,
          blendOnColors: false,
        ),
        keyColors: const FlexKeyColors(),
        visualDensity: FlexColorScheme.comfortablePlatformDensity,
        useMaterial3: true,
      ),
      darkTheme: FlexThemeData.dark(
        colors: const FlexSchemeColor(
          primary: Color(0xff1145a4),
          primaryContainer: Color(0xff9fb4da),
          secondary: Color(0xffb61d1d),
          secondaryContainer: Color(0xffe1a4a4),
          tertiary: Color(0xff376bca),
          tertiaryContainer: Color(0xffcfdbf2),
          appBarColor: Color(0xffcfdbf2),
          error: Color(0xffb00020),
        ),
        surfaceMode: FlexSurfaceMode.highScaffoldLowSurface,
        blendLevel: 15,
        appBarStyle: FlexAppBarStyle.background,
        appBarOpacity: 0.90,
        subThemesData: const FlexSubThemesData(
          blendOnLevel: 30,
        ),
        keyColors: const FlexKeyColors(),
        visualDensity: FlexColorScheme.comfortablePlatformDensity,
        useMaterial3: true,
      ),
      home: const MyApp(),
    ),
  );
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Container(
        width: double.infinity,
        height: 600.0,
        color: const Color(0xffb61d1d), // I copied the value of secondary here 
        // color: Theme.of(context).colorScheme.secondary, // This color is different from the value of secondary
      ),
    );
  }
}

[rydmike]

Hi @Errechydy,

Thank you for your question.

When you pass in const FlexKeyColors() to keyColors, you are enabling usage of key color based seed generated Material 3 ColorScheme.

If you do not want to use Material 3 based seeding generated ColorScheme, but want to use the exact colors you defined you can just delete keyColors: const FlexKeyColors(), in your setup.

If on the other you do want to use it, then when using the default FlexKeyColors() it is the same as using ColorScheme.fromSeed with your primary color, in the light theme case:

ColorScheme.fromSeed(seedColor: Color(0xff1145a4), brightness: Brightness.light)

The resulting ColorScheme from that operation, will not contain any of the actual provided colors in your input colors, in the ColorScheme and in this case only the primary color is even used to seed generate the ColorScheme using the Material Color system and tonal palettes. This is expected behavior in Flutter, FCS and Material 3 based seed generated ColorSchemes. And yes the expected secondary color outcome in Material 3 is a greyish color version of the primary color you used as seed color.

The process of this described in the docs e.g. here https://docs.flexcolorscheme.com/playground#seeded-colorscheme and here https://docs.flexcolorscheme.com/api_guide#generated-colorscheme

You can also learn much more about this from myFlutter Vikings talk https://rydmike.com/blog_vikings_2022_talk and its slides on M3 ColorScheme https://docs.google.com/presentation/d/1F7LXlMkD4Z5Eqkvw8uwMQBgBX52IiLqe3yODuakmLQo/edit#slide=id.p45

How do I get the colors I defined and still use a M3 seed generated ColorScheme?

Using FlexColorScheme you can for starters tell FCS keyColors to also use secondary and tertiary colors as input for seed generation, for those color groups, and not use primary for everything, like Flutter SDK only supports at the moment via ColorScheme.fromSeed.

Additionally you can use another tones setup that produces a seed generated ColorScheme where secondary and tertiary colors are using chroma as given in the seed colors for their tonal group. This makes them more colorful than the M3 "grey" variant of used seed color that it makes secondary by default in M3 design due to the max chroma limit used for the tonal palette generation.

  keyColors: const FlexKeyColors(
    useSecondary: true,
    useTertiary: true,   
  ),
  tones: FlexTones.vivid(Brightness.light),

This would still not give you the exact colors that you have as seed key colors, in the ColorScheme, but it would be pretty close now already, it would look like:

When using seeded color schemes the inputs are not ending up in the produced ColorScheme, but you can also tell it to do so in the produced output seeded color scheme via FlexKeyColors properties keepPrimary, keepSecondary etc.

  keyColors: const FlexKeyColors(
    useSecondary: true,
    useTertiary: true,
    keepPrimary: true,
    keepSecondary: true,
    keepTertiary: true,
  ),
  tones: FlexTones.vivid(Brightness.light),

Above, I did not lock down the container colors, but instead let them still use the seed generated values from their tonal palettes. I did so because the colors you used are not entirely compatible with what the M3 color system expects to find in those colors in relation to their none container color values.

The secondary color is also quite special in M3 design fulfilling ColorSchemes, and the M3 widget styling and design expects it to be more muted and less prominent version of "primary". Using color hue's that are bit off color from primary and more muted/pastel/greyish will work well though even if they do not use the exact same hue as primary color.

Tertiary has more freedom and can well be used as additional color the gets more attention.

The container color should always have a certain relation to their none container version.

It is also a good idea to in the main colors avoid very close color overlap with the M3 error colors.

Material 3 color system fulfilling ColorSchemes are quite picky and difficult to design by hand, therefore seeding is often preferred. Locking down a few brand color values for the actual primary and e.g. tertiary color works pretty well though. For the rest of them I recommend going with seed generation, if you know the color system and what is expected where, you can of course hand tweak it or even design it fully by hand as well.

If you use totally wild ColorScheme in M3 mode, that is not design as the M3 Color system expects, widgets that have been migrated to support M3 styles when M3 is enabled may end up looking a bit odd by, it all depends on used colors of course.

---

If you use the ThemesPlayground you can play with Seed generation, keeping the inputs, different tones mapping and chroma selections, to find these settings that suite your needs, also with the custom colors as input that you used in above example.

---

You can also use a completely custom made colorScheme as input to FCS via its colorScheme property, this is shown in this discussion #85.

---

Hope this helps and explains what it is going. The behavior is as designed and expected, Material 3 seed generated ColorScheme are however an entirely new ball game in Material app design. I do recommend studying the M3 guide, for many hours: https://m3.material.io/, well if it is of interest 😄

I will close this issue and move it to discussions, in hope that the answer can be helpful and found later by others as well.

Good question, definitely not a simple design topic, but easy enough to configure in FCS.

[Errechydy]

Thanks for your detailed answer, i wasn't expecting that M3 comes with all this. it's a bit confusing, i will give it a couple hours like you said to understand it.

I thought when using Theme.of(context).colorScheme.secondary it would act like a variable, and it would reflect all the changes that are happening

It would be better if you add a section on FCS with all the info above, because this is something you always use in every app, where you want to use some theme's colors in places that doesn't have it as default if that make sense.

[rydmike]

Hi @Errechydy,

Yes I know it is quite a complex topic, and the Material 3 color system and how it should be used is not really described at all in any Flutter docs. Designers are supposed to (well have to) study the Material 3 guide and figure out what to do based on it.

Caused of unexpected result

The Theme.of(context).colorScheme.secondary does indeed contain the value you specified that it should have.

It was only that when you specified in FCS that you want:

keyColors: const FlexKeyColors(),

You gave the entire ColorScheme theme a new value, with all new colors, that in your case was equal to doing this in Flutter:

ColorScheme.fromSeed(seedColor: Color(0xff1145a4), brightness: Brightness.light)

and assigned its result to ThemeData(colorScheme) for the light theme, which then became the data you accessed via Theme.of(context).colorScheme.

If you delete the row:

keyColors: const FlexKeyColors(),

You will get the result you expected. With the ColorScheme you manually defined, it does however not meet the Material 3 color system guidelines.

Enabling Material 3

Enabling useMaterial3 does not do anything to the produced colorScheme in ThemeData, it only tells all the UI widgets (for those that implement M3 in Flutter, far from all do it yet) to use their styles and behavior that match their Material 3 design.

All the widgets of course use Theme.of(context).colorScheme to get the colors they should use, this is true in M3 and M2 (well OK some old widgets still use the direct ThemeData colors in M2 mode, for their default colors, which is another mess in Flutter that is going away).

If the colors stored in this colorScheme, that different widgets use different colors from via their M3 default design, do not conform to how the Material 3 design and color system expects them to be, the Widgets may end up looking odd, or at least not as intended to by the M3 spec.

Same of course applies to Material 2, but most widgets only use very few colors from the ColorScheme and the expected internal relations between colors is much simpler, so there are fewer things to mess up when defining it manually.

Making M3 Compliant ColorScheme

Since M3 compliant ColorScheme's have such complex internal relationships and design requirements, the Material Team has made a color utility (https://pub.dev/packages/material_color_utilities) to help designers create such ColorSchemes.

ColorScheme.fromSeed

Flutter SDK also depends on this package and devs can use it via:

https://api.flutter.dev/flutter/material/ColorScheme/ColorScheme.fromSeed.html

Material 3 Theme Builder

Alternatively one may use the web M3 ColorScheme tool: https://m3.material.io/theme-builder#/custom and export the ColorScheme definition. FCS can also accept a pre-made ColorScheme as input. This is useful if you have one that a designer specified.

Putting your primary color into the official web too gives the same grey secondary too btw, it uses the same seeding algorithm:

With the WEB tool you can put in separate seed colors for secondary and tertiary as well, even neutral if you like. With Flutter's ColorScheme.fromSeed you cannot do that.

FlexColorScheme

With keyColors in FCS you can though, and you can easily seed and lock down "brand" colors.

Using keyColors and seed generated M3 compliant ColorScheme is described in the FCS docs here and here. The 3rd tutorial also goes though using keyColors and seed generated M3 ColorScheme here and tutorial 4 expands on it further here by demonstrating locking input colors here.

FlexSeedScheme :: FlexColorScheme.fromSeeds

Under the hood FlexColorScheme also uses Material Color Utilities (https://pub.dev/packages/material_color_utilities, but it does it via https://pub.dev/packages/flex_seed_scheme that reimplements some of the tools in Material Color Utilities and adds much much more freedom and config options into how the seeding algorithm produces tonal palettes and how those tones are mapped to ColorScheme colors.

When you use FCS and enable seed generated schemes you are using that engine to generate the M3 compliant ColorScheme from selected built-in, originally M2 designed ColorSchemes, or using colors you gave it, like you did. In the Themes Playground this can be done via the customizable theme (last one), and in it using own colors as input, which if seeding is enabled, gets used as key colors for the seed generated ColorScheme.

Seeing it all in Themes Playground

If you have a 4k screen at native res, you can create a view like below in Themes Playground, then you can see many useful settings, and their dependencies/interactions as you modify things at a glance, on colors and in the API code. Like the effective ColorScheme in Seeded ColorScheme, the main input and effective colors are shown in Input Colors.

Enabling Seeded ColorScheme is an input modifier. If you disable it, you can use some older FCS M2 based reduced color input ColorScheme generation/modifications as well. Plus in dark mode you can compute the dark theme from the light theme. Using seeded ColorScheme does that automatically, well in a way since light and dark themes are based on same seed colors, only using different tones from the produced tonal palettes.

Wrap up

Having studied and used M3 ColorScheme and the M3 guide quite a lot, I guess this all seems obvious to me, and I've written about as much about it as I can come up with. I'm not sure devs read docs though, I know I don't always do it 😄 I should probably make some videos about it as well, to explain it further.

Vikings theming talk

Hopefully the edited version from the recordings of my Vikings talk comes out soon, because there I also explain and open the mystery behind seed generated ColorSchemes. The streamed version has so poor video quality that it is not watchable. One would have to use the slides I published, look at them and listen to the talk, nobody will do that either, hehe.

https://rydmike.com/blog_vikings_2022_talk

What else can I do to improve the info?

I would love some input on what kind of additional docs or info that you think would have helped you? Where should it be? What should it say?

The doc comments on keyColors in FlexThemeData.light/dark and FlexColorScheme.light/dark says this btw:

    /// To use and activate Material 3 color system based [ColorScheme]
    /// defined via key colors for primary, secondary and tertiary colors and
    /// the [TonalPalette] generated by these key color values, pass
    /// in a [FlexKeyColors] to [keyColors].
    ///
    /// By default it is not defined (null), and a traditional manually
    /// configured color scheme will be created based on input property values
    /// or the passed in [colorScheme].
    ///
    /// If a [FlexKeyColors] instance is passed in, the key color seeding
    /// behavior depends on properties defined in the [FlexKeyColors]
    /// instance. The default constructor makes one where
    /// [FlexKyColors.useKeyColors] is true, it will automatically enable usage
    /// of key colors and from them generated color scheme.
    ///
    /// For more information on Material 3 color system and usage of key colors
    /// to generate tonal palettes and tones, see:
    /// https://m3.material.io/styles/color/the-color-system/key-colors-tones
    final FlexKeyColors? keyColors,

[Errechydy]

Hi @rydmike

I have two points:
1 - Your package is so far the best well documented package i've ever seen so far, you've talked and explained the details of the details of almost everything, but the thing is sometimes that can get the opposite results, especially for someone who's not very experienced with Flutter in this case. Having a lot of informations about something means that you need to read A LOT so you can have general idea about it. most of us unfortunately don't really do that.

2 - You mentioned that The doc comments on keyColors says this and that, but the problem is that how do i know that the keyColors is the parameter that prevents me from having the rights colors when using Theme.of(context).colorScheme in the first place so i can go and read about it? you know what i mean :).

In my opinion i think it would be better if you address both pro and beginners in different ways, if you're a pro and want to go deep then you can go here and read about everything, and if you are a beginner or you just want things to work then go here

I will put a few things together this weekend and send it to you, the section would be like Quick start or something similar

[rydmike]

Thanks @Errechydy,

1. I agree, and if you can assist with a quick start guide, from a beginners point of view that would be an awesome and a very welcome addition to the docs. Like you say, I'm too deep in it, so the challenge for me is I have no idea what that would be and where it would fit. Since it is all obvious to me and "all" is already documented, with as you rightly point out, excruciating details 😄 The "too much docs" is just how I roll I guess, and I get equally frustrated when packages or framework docs don't do that, hehe.

---

2. The keyColors prop is actually not a default, so it is nothing one gets by accident, by default things work as you expected them to. It must be added manually as a deliberate choice, or seeding was enabled in Themes Playground and it added it to the API setup code. In the Playground if you enable it, you see the effective theme colors and can see that the effective ColorScheme and its colors changed, based on M2 color system seed choice and settings, when you enable Seeded ColorScheme.

Plus there the UI texts change with choices to explain what is happening:

---

Looking forward to your proposal and would love to have you onboard to make the experience simpler for beginners! 💙