A Flutter package to make and use beautiful color scheme based themes

flexcolorscheme

flexcolorscheme helps you make beautiful color scheme based flutter themes, with optional level of primary color branded surfaces. the created themes are based on the same concept as flutter’s colorscheme based themes, but with a few interesting twists and features.

when you design flutter applications you should base the colors of your application on a light theme mode
colorscheme and a dark theme mode colorscheme. then make your light and dark themedata from these color schemes, and in
your materialapp use these themes for the light and dark themes. this gives you an application that uses the defined
color scheme on the built-in material ui widgets, well on most of them anyway. flutter’s themedata.from a
colorscheme has a few gaps, the used color scheme is not consistently applied to all standard material ui widgets.

flexcolorscheme corrects these minor inconsistencies and gaps that exist in the current version of flutter’s
themedata.from factory. it also makes a few opinionated, but subtle theme modifications compared to the
themedata.from themes created from a colorscheme. these topics are covered in detail in the last chapter and in the article you can find a
visual presentation of the differences.

this is just the basic part, flexcolorscheme can do some other nice theme design tricks.
if you have seen the flutter flexfold web demo application, then you
have already seen flexcolorscheme in action. the flexfold demo app uses this package for its fancy theming and to
enable effortless switching between all the themes it uses. the package included examples in the
tutorial chapter, show you how the flexfold demo app theming is done with this package.

color branded backgrounds and surfaces

the material guide briefly mentions
color branded surfaces. with flexcolorscheme you
can easily create such primary color branded themes. this is done by using the four built-in strengths for blending in
primary color into surface and background colors, while avoiding blending it in with the scaffold background color,
for all but the highest strength. it is quite interesting what a bit of extra flair and purposefully designed feeling it
can result in when used appropriately.

nuanced scheme set from one color

a flexcolorscheme can like flutter’s standard colorscheme be created by specifying all the required
scheme colors, but you can also specify just the primary color and get all other colors needed for a complete color
scheme computed based on just the provided primary color.

there is a helper class with a factory flexschemecolor.from that can do this for you. another helper can
also create a computed matching dark scheme, from a defined light scheme this is done with flexschemecolor.todark.
this works regardless of if you created a fully specified custom light scheme or just one from a single color.
these features are presented and explained in the tutorial with
example 4 and
example 5.

what about my theme additions?

flexcolorscheme does not get in the way of adding your own additional custom theming to your application.
when you have defined your flexcolorscheme, you make a theme based on its scheme with flexcolorscheme.totheme,
that returns a themedata object that you can use like any other themedata object. you can then of course
override this returned theme data and add additional custom sub-theming to it with the normal
themedata copywith method before passing it on to your app.

built-in color schemes

color schemes are no fun without some built-in example schemes to use and play with.
flexcolorscheme comes with 20 ready to go color schemes that you can use in your apps if you like.
here you can see phone sized screen-shots of
them all, in both light and dark theme-mode.

the bundled examples are all tuned matching light and dark theme pairs. the first two color schemes are actually
the flutter and material design guide examples of light and dark mode themes, and the flutter high contrast light and
dark color versions as well. so ok, there are actually “only” 18 new ready-made color schemes.

there is of course no need to use any of the built-in color schemes, the package examples show how you can easily
make your own custom schemes, maybe the built-in examples will inspire you.

installing and using

in the pubspec.yaml of your flutter project, add the following dependency:

dependencies:
  flex_color_scheme: any

in your library file add the following import:

import 'package:flex_color_scheme/flex_color_scheme.dart';

you can now start using flexcolorscheme based themes in your application. the easiest way to do so is to use one
of the 20 built-in color schemes. the schemes have enums that you can use to refer to them. their corresponding
data object holds name, description and separate scheme data for each schemes’ light and dark mode.

as a simple use case, take the default flutter counter app, do the above installation and select one of the
built-in flexcolorscheme’s schemes to use with it.

in this example we use “oh mandy red” scheme that is represented by enum value flexscheme.mandyred.

there is a flexcolor.schemes map with the flexscheme enums as keys, with corresponding predefined
flexschemedata objects as values. we use this flexschemedata object’s light colors for the light color scheme that
we make with the flexcolorscheme.light factory by assigning the light flexschemecolor set, from the
predefined flexschemedata we got with the enum key from the map, to the colors property of the
flexcolorscheme.light factory.

then we use totheme to let the resulting flexcolorscheme.light object return the theme this factory defines,
that we finally assign to the materialapp theme property.

the above may sound a bit complicated, but it is just one line of code:

theme: flexcolorscheme.light(colors: flexcolor.schemes[flexscheme.mandyred].light).totheme,

for the dark theme we do the equivalent using the flexcolorscheme.dark factory and the dark version of the
flexschemecolor that we have in our flexschemedata object from the flexcolor.schemes map via
the same flexscheme.mandyred key.

darktheme: flexcolorscheme.dark(colors: flexcolor.schemes[flexscheme.mandyred].dark).totheme,

we also set the app’s thememode property to thememode.system so that the used device can control if the app
uses its light or dark theme, based on the device system setting for light and dark theme.

totally just one property modified, and two properties added to the default counter app, plus the package
import of course. the modified materialapp from the flutter default counter app is shown below.

  class myapp extends statelesswidget {
    @override
    widget build(buildcontext context) {
    return materialapp(
      title: 'flutter demo',
      // the mandy red light theme.
      theme: flexcolorscheme.light(
        colors: flexcolor.schemes[flexscheme.mandyred].light,
      ).totheme,
      // the mandy red dark theme.
      darktheme: flexcolorscheme.dark(
        colors: flexcolor.schemes[flexscheme.mandyred].dark,
      ).totheme,
      // use dark or light theme based on system setting.
      thememode: thememode.system,
      home: myhomepage(title: 'flutter demo home page'),
    );

this gives us the following counter app look:

perhaps not so exciting, that is because the basic counter app uses very few features and widgets, so it cannot really
illustrate the result very well. this is why the included samples contain demo ui, that is not really at all relevant
to using flexcolorscheme and is really only there to better demonstrate the result.

the default example 1, is just a repeat of the above example, but with a thememode 3-way toggle
switch, an effective theme colors widget, plus a bunch of dummy commonly used material ui widgets.

can i use different built-in schemes for my light and dark themes?
yes this is possible, just use different enums values as keys for the light and dark flexcolorscheme factories
when you get the predefined flexschemedata from the map. if the colors in used schemes are a bit related this
can be used to create nice and unique light and dark combinations of the predefined schemes.

you can even apply a flexschemecolor that has data that was designed for a light theme to the flexcolorscheme.dark
factory and wise versa. the result will just not be as useful or pretty.
the rationale for the slightly involved structure, is to keep it flexible, but at the same time provide self
documenting api guidance on how the data was designed to be used and consumed.

default sample application

the package contains five different example applications with increasing complexity.

to try the simplest of them, example 1 in on a device or simulator,
download the repository and run the example:

cd example/
flutter run --release

the result is a sample app that uses one of the built-in “oh mandy red” color schemes as its theme. has a
light/dark/system theme mode switch, includes a theme colors and material ui widget samples, so you can
see the theme colors and theme’s impact on common material ui widgets.

building the examples
if you cloned the repository to build the examples, you can open the package /example folder with your ide to build
the above default example. this example is the same as the example in the /example/lib/example1 folder.

if you want to build the other examples, without setting up different configurations in your ide for the different
main files, you can copy and paste the wanted example’s main.dart code into the /example/lib/main.dart file to
build it from your ide.

after copying the other example content, change the relative import for the “all shared imports” file to:
import 'all_shared_imports.dart';
and for examples 4 and 5, also the “sub page” import to:
import 'shared/sub_page.dart';

live web demos of the examples

if you want to take a quick look at all the example applications, you can try live web versions of them.

example 1 represents the simplest use case, to just use one of the
built-in color schemes as your application theme and toggle between its light
and dark variant, or allow device mode setting to control if the dark or light theme is used.

example 2 is like example 1, but here we use custom colors
to make a custom scheme and turn it into a theme.

in example 3 we can toggle the active theme between 3 different
predefined color schemes, plus the custom one we made in example 2.

in example 4 we can select any of the different built-in themes
and three custom ones we made.

example 5 is the last, and most complex one of the examples and presents
more configuration options that you can modify interactively.
this example is best seen and tested on a tablet, desktop or desktop web browser, rather than on a phone, but it
certainly works on a phone sized canvas too. this example is explained in more detail further below.

flexfold demo

a really fancy example of flexcolorscheme usage is the flexfold demo app.

it might look and feel complicated, but it is actually only slightly more involved than the above example nr 5, that
has almost all the same theming features and exactly the same themes as the flexfold demo app.
go through the examples, and you will be ready to make cool interactively custom themed apps in no time.

tutorial

in this tutorial we go through all the bundled examples and explain the flexcolorscheme relevant topics.
for simplicity the example applications do not use any advanced state management solution. the key part for each
example is always in the used stateful materialapp, where all the scheme setup for the themes are made. the rest of
the content in the examples is just there to make a visual presentation of the resulting theme from the used
color scheme.

homepage for the examples

the content of the homepage in all these examples is not really so relevant for using flexcolorscheme based
application theming. the critical parts are in the example materialapp theme definitions. the homepage mostly
contains ui to visually show what the defined themes look like when used in an application with commonly
used widgets. in example 5 we can also make interactive changes to used flexcolorscheme api values to
see and learn more about how they work.

in all the examples we pass in the flexschemedata object we used for the active theme to the application’s homepage.
this is not really needed in order to use flexcolorscheme based themes, but we use it to be able to show
the active theme name and its description in the examples. we also use its color data for the 3-way theme mode switch
flexthememodeswitch, that uses the light and dark scheme colors in its theme toggle widget for the theme mode
option buttons, that also show the 4 main colors in the active light and dark scheme.

optional flexthememodeswitch

one special feature on the homepage of all the examples is the flexthememodeswitch. it is the ui widget used
for the 3-way theme mode switch used in all the examples to change the active theme mode.

using the switch is very simple, give it the active theme mode, the active flexschemedata scheme and use the
onthememodechanged callback for changes, and act on it in the materialapp thememode to actually toggle used
mode and theme.

flexthememodeswitch(
  thememode: thememode,
  onthememodechanged: onthememodechanged,
  flexschemedata: flexschemedata,
),

using the flexthememodeswitch 3-way theme mode switch is optional and not required to
use flexcolorscheme based themes. it is a simple, but different theme mode switch design and was included
as a bonus feature in the flexcolorscheme package. it was added based on a request after it
had been observed in the wild in the flexfold demo app.

in the flexfold demo app the switch was originally a fairly fixed design, now flexthememodeswitch has many
properties that allow you to customize it extensively. you can find its api
reference here
and its companion, the flexthememodeoptionbutton
api reference here.

with the api you can customize the look of the flexthememodeswitch, here are some examples:

the flexthememodeoptionbutton is typically used by the flexthememodeswitch, but it can also be used as a part
of other theme related indicator widgets. like for example the scrolling horizontal list used in the flexfold demo.
where it is used as theme indicator in a list, used as a way to show all available themes and select the active theme,
just as an alternative to the rather plain popup menu.

example 1 use a predefined color scheme

the first and simplest example shows how you can use a predefined color scheme in flexcolorscheme to
define light and dark themes using the scheme, and then switch between the light and dark mode. a theme showcase
widget shows the theme with several common material widgets.

this is example basically a repeat of the flutter default counter app modification example above, but with a different
homepage and a way to change the materialapp active thememode property value via the flexthememodeswitch
switch on the homepage and an ordinary callback.

void main() => runapp(const demoapp());

class demoapp extends statefulwidget {
 const demoapp({key key}) : super(key: key);
 @override
 _demoappstate createstate() => _demoappstate();
}

class _demoappstate extends state<demoapp> {
 // used to select if we use the dark or light theme.
 thememode thememode;

 @override
 void initstate() {
   thememode = thememode.light;
   super.initstate();
 }

 @override
 widget build(buildcontext context) {
   // define which predefined flexscheme to use.
   // go ahead and try some other ones too.
   const flexscheme usedflexscheme = flexscheme.mandyred;
   return materialapp(
     debugshowcheckedmodebanner: false,
     title: 'flexcolorscheme',
     // a light scheme, passed to flexcolorscheme.light factory, then use  
     // totheme to return the resulting theme to the materialapp theme.
     theme: flexcolorscheme.light(
       colors: flexcolor.schemes[usedflexscheme].light,
       // use comfortable on desktops instead of compact, devices use default.
       visualdensity: flexcolorscheme.comfortableplatformdensity,
     ).totheme,
     // we do the same thing for the dark theme, but using flexcolorscheme.dark 
     // factory and the dark flexschemecolor in flexcolor.schemes.
     darktheme: flexcolorscheme.dark(
       colors: flexcolor.schemes[usedflexscheme].dark,
       visualdensity: flexcolorscheme.comfortableplatformdensity,
     ).totheme,
     // use the above dark or light theme, based on active thememode 
     // value light/dark/system.
     thememode: thememode,
     // the homepage, with its properties. in this example we pass the
     // current thememode, change it via its call-back. we also pass
     // the currently used flexschemedata to the homepage so we can use
     // it to display some info about it.   
     home: homepage(
       thememode: thememode,
       onthememodechanged: (thememode mode) {
         setstate(() { thememode = mode; });
       },
       // pass in the used active flexschemedata so we can 
       // use its properties on the homepage.
       flexschemedata: flexcolor.schemes[usedflexscheme],
     ),
   );
 }
}

there is one more small addition
example 1 and the other examples, use comfortable adaptive platform visual density via
flexcolorscheme.comfortableplatformdensity, instead of the counter app’s normal
visualdensity.adaptiveplatformdensity.

this is an alternative that on desktop app’s results in the flutter
comfortable visual density being used, instead of compact. on devices, they both result in default large
small device friendly visual density. this helper function was added to provide an easy option for using a bit larger
ui elements also on desktop and web apps while keeping the correct size for devices. this is useful if the desktop
and web versions are occasionally used on computers with touch screens. the comfortable density is a nice
balance that still look compact enough to be desktop like, while providing a bit
more touch friendly space without looking like an overblown device ui on a desktop.

building and running example 1

when you build and run example 1 you get a sample application that looks like this in light and dark mode:

try example 1 live on the web here.

in the app, scroll down to see the theme showcase further below, it presents the theme with common material widgets.
this simple first example is not using primary color surface branding, it is just a normal theme with a few
convenient fixes for some theme design gaps in flutter’s own themes created with themedata.from a colorscheme.

example 2 create a custom color scheme

this example shows how you can define your own flexschemedata and create flexcolorscheme based themes from it.
a theme showcase widget shows the theme with several common material widgets.

the full code is not shown in the tutorial, please see the code in the package folder
flex_color_scheme/example/lib/example2
for the entire example.

to make a custom color scheme, we will for simplicity just define it as a constant in this example.
we make a flexschemedata object with a name, description and scheme colors defined with
flexschemecolor for the light and matching dark scheme. in this example we use dark purple and deep green
and matching desaturated versions for the dark scheme.

const flexschemedata customflexscheme = flexschemedata(
  name: 'toledo purple',
  description: 'purple theme created from custom defined colors.',
  light: flexschemecolor(
    primary: color(0xff4e0028),
    primaryvariant: color(0xff320019),
    secondary: color(0xff003419),
    secondaryvariant: color(0xff002411),
  ),
  dark: flexschemecolor(
    primary: color(0xff9e7389),
    primaryvariant: color(0xff775c69),
    secondary: color(0xff738f81),
    secondaryvariant: color(0xff5c7267),
  ),
);

then we use this flexschemedata customflexscheme instance light and dark properties as scheme colors
for the flexcolorscheme.light and dark factory for each theme mode and totheme to get the themes they define.

this setup is totally equivalent to how we used one of the built-in predefined flexschemedata objects in example 1,
in this case we just defined our own custom flexschemedata in customflexscheme.

  :
  @override
  widget build(buildcontext context) {
    return materialapp(
      debugshowcheckedmodebanner: false,
      title: 'flexcolorscheme',

      theme: flexcolorscheme.light(
        colors: customflexscheme.light,
        visualdensity: flexcolorscheme.comfortableplatformdensity,
      ).totheme,
      
      darktheme: flexcolorscheme.dark(
        colors: customflexscheme.dark,
        visualdensity: flexcolorscheme.comfortableplatformdensity,
      ).totheme,
      
      home: homepage(
        thememode: thememode,
        onthememodechanged: (thememode mode) {
          setstate(() { thememode = mode; });
        },
        // we use our custom flexschemedata on the homepage too.
        flexschemedata: customflexscheme,
      ),
    );
  }
}

when you build and run example 2 you get a sample application that looks like this in light and dark mode:

try example 2 live on the web here.

scroll down to see the theme showcase widgets further below, presenting the theme with some widgets. this example is
not using primary color surface branding, it is just a normal theme with a few convenient fixes for certain
theme properties.

example 3 switch between different color schemes

this example shows how you can use three built-in color schemes, add a custom scheme and then use all four as
selectable flexcolorscheme based theme options in an application. the example also uses strong branded surface
colors. a theme showcase widget shows the theme with several common material widgets.

the full example code is not shown here, please see the code in the package folder
flex_color_scheme/example/lib/example3
for the entire example.

the customflexscheme flexschemedata definition is the same as in example 2, it is not repeated below.
in the example below, if we select the flexscheme.custom option, we use our customflexscheme object, otherwise
the selected built-in scheme we selected on the homepage is used. we also set the surface style to
flexsurface.strong, for a strong primary color branded blend in surfaces and backgrounds.

:
class _demoappstate extends state<demoapp> {
  thememode thememode;
  // used to store which flexschemedata option we selected
  flexscheme flexscheme;

  @override
  void initstate() {
    thememode = thememode.light;
    flexscheme = flexscheme.hippieblue; // default selected theme
    super.initstate();
  }
  @override
  widget build(buildcontext context) {
    return materialapp(
      debugshowcheckedmodebanner: false,
      title: 'flexcolorscheme',

      theme: flexcolorscheme.light(
        // when we select the custom flexscheme on the home 
        // page, we get the custom enum value back and use the custom 
        // scheme we defined, otherwise we use the selected scheme 
        // from the the built in map.
        colors: flexscheme == flexscheme.custom
            ? customflexscheme.light
            : flexcolor.schemeswithcustom[flexscheme].light,
        // this surface style gives a strong blend of primary
        // color on surfaces and background colors.
        surfacestyle: flexsurface.strong,
        visualdensity: flexcolorscheme.comfortableplatformdensity,
      ).totheme,
      // just a repeat with equivalent setup for dark theme.
      darktheme: flexcolorscheme.dark(
        colors: flexscheme == flexscheme.custom
            ? customflexscheme.dark
            : flexcolor.schemeswithcustom[flexscheme].dark,
        surfacestyle: flexsurface.strong,
        visualdensity: flexcolorscheme.comfortableplatformdensity,
      ).totheme,
      thememode: thememode,

      home: homepage(
        thememode: thememode,
        onthememodechanged: (thememode mode) {
          setstate(() { thememode = mode; });
        },
        // we pass the enum value of the active scheme to the homepage.
        flexscheme: flexscheme,
        // where we can select a new scheme and get its enum value back.
        onflexschemechanged: (flexscheme selectedscheme) {
          setstate(() { flexscheme = selectedscheme; });
        },
        // we take care to pass in selected built-in scheme data 
        // or the custom one we made if it is selected.
        flexschemedata: flexscheme == flexscheme.custom
            ? customflexscheme 
            : flexcolor.schemeswithcustom[flexscheme],
      ),
    );
  }
}

in this example on the homepage we removed the option to allow the theme mode to depend on the system theme mode
setting, by setting showsystemmode to false, thus removing this option from switch.

  :
  flexthememodeswitch(
    thememode: thememode,
    onthememodechanged: onthememodechanged,
    flexschemedata: flexschemedata,
    showsystemmode: false,
  ),
  :

these are the four resulting different themes with their light and dark modes, that we can select and
use with this example.

hippie blue scheme in light and dark mode.

green money scheme in light and dark mode.

red red wine scheme in light and dark mode.

our custom toledo purple scheme in light and dark mode.

try example 3 live on the web here.

example 4 switch between all built in color schemes and three custom ones

this example shows how you can use all the built-in color schemes, plus three custom schemes.
how to interactively select which one of these schemes is used to define the active theme. the example also uses
medium branded background and surface colors. a theme showcase widget shows the theme with several common material
widgets. a sub-page is also available that shows the same theme applied when opening another page, that in flutter
just inherits the same theme.

the full example code is not shown here, please see the code in the package folder
flex_color_scheme/example/lib/example4
for the entire example.

in this example we set the surface style to flexsurface.medium, for medium primary color branded surfaces.

the example is otherwise fairly straight forward. we use the built in flexcolor.schemeslist to access all the
pre-defined flexschemedata objects, with its schemes. unpack it with the spread operator into a new
custom myflexschemes list, and add our three custom schemes in flexschemedata objects to the end of this new list.
we then access the list with index number, that we simply change with a popup menu on the homepage.

that is the general principle, let’s go through it step by step.

first, let’s begin by defining the same colors that we used in example 2 and 3 for our first custom color. in this
case we also assign the same color that we used for secondaryvariantscheme color, to the optional appbarcolor.
this is done because the built-in schemes use their secondary variant color as their custom app bar color, it could
of course be any color, but for consistency we will do the same for our custom flexschemecolors.

 void main() => runapp(const demoapp());
 // create a custom flex color scheme for a light theme.
 const flexschemecolor myscheme1light = flexschemecolor(
   primary: color(0xff4e0028),
   primaryvariant: color(0xff320019),
   secondary: color(0xff003419),
   secondaryvariant: color(0xff002411),
   appbarcolor: color(0xff002411),
 );
 // create a corresponding custom flex color scheme for a dark theme.
 const flexschemecolor myscheme1dark = flexschemecolor(
   primary: color(0xff9e7389),
   primaryvariant: color(0xff775c69),
   secondary: color(0xff738f81),
   secondaryvariant: color(0xff5c7267),
   appbarcolor: color(0xff5c7267),
 );

we can build a scheme the long way, by specifying all the required hand-picked scheme colors, like above, or we can
also build schemes from a single primary color. with the flexschemecolor.from factory. with the factory the
only required color is the primary color, the other colors will be computed. you can optionally also provide the
primaryvariant, secondary and secondaryvariant colors with the factory, but any color that is not provided will
always be computed for the full set of 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 app
bar color will in this case also receive the same color value as the one that is computed for secondaryvariant color,
this is the default with the flexschemecolor.from factory if the color is not specified.

 final flexschemecolor myscheme2light =
   flexschemecolor.from(primary: const color(0xff4c4e06));

 final flexschemecolor myscheme2dark =
   flexschemecolor.from(primary: const color(0xff9d9e76));

for our 3rd custom scheme we will define primary and secondary colors for a light color scheme, but no variant colors.
we will not make any dark scheme definitions either.

 final flexschemecolor myscheme3light = flexschemecolor.from(
   primary: const color(0xff993200),
   secondary: const color(0xff1b5c62),
 );

then we create a list with all the flexschemedata objects we will use as our schemes in this example,
starting with all the built-in ones and adding our three custom ones at the end.

a flexschemedata object stores name and description, plus the separately defined color schemes for light and
matching dark scheme colors. as a rule of thumb, the dark scheme colors must be much less saturated than light ones.
using the same colors in light and dark color schemes does not produce nice looking or usable dark and light
theme mode pairs. you can read more in the material design guide about selecting suitable dark
theme colors.

we first unpack the predefined flexschemedata into the list myflexschemes, add our own light and
dark scheme definition pairs as flexschemedata to the end. for our last custom flexschemecolor myscheme3light we
did not make a matching dark scheme pair, we instead use the .todark() method on the light scheme to get one
automatically computed from the defined light scheme colors.

 final list<flexschemedata> myflexschemes = <flexschemedata>[
   // add all the predefined flexcolor schemes
   ...flexcolor.schemeslist,
   // then add our first custom schemes to the flexschemedata list.
   const flexschemedata(
     name: 'toledo purple',
     description: 'purple theme, created from full custom defined color scheme.',
     light: myscheme1light,
     dark: myscheme1dark,
   ),
   // do the same for our second custom scheme.
   flexschemedata(
     name: 'olive green',
     description: 'olive green theme, created from primary light and dark colors.',
     light: myscheme2light,
     dark: myscheme2dark,
   ),
   flexschemedata(
     name: 'oregon orange',
     description: 'custom orange and blue theme, from only light scheme colors.',
     light: myscheme3light,
     // we create the dark desaturated colors from the light scheme.
     dark: myscheme3light.todark(),
   ),  
 ];

the setup of the stateful materialapp is as simple as the previous examples.

 :
 class _demoappstate extends state<demoapp> {
   thememode thememode;
   // used to select which flexschemedata we use from a popup menu.
   int themeindex;
 
   @override
   void initstate() {
     thememode = thememode.light;
     themeindex = 6; // start with index 6, the brand blue colors.
     super.initstate();
   }
 
   @override
   widget build(buildcontext context) {
     return materialapp(
       debugshowcheckedmodebanner: false,
       title: 'flexcolorscheme',

       theme: flexcolorscheme.light(
         colors: myflexschemes[themeindex].light,
         surfacestyle: flexsurface.medium,
         visualdensity: flexcolorscheme.comfortableplatformdensity,
       ).totheme,
       
       darktheme: flexcolorscheme.dark(
         colors: myflexschemes[themeindex].dark,
         surfacestyle: flexsurface.medium,
        visualdensity: flexcolorscheme.comfortableplatformdensity,
       ).totheme,

       thememode: thememode,
       
       home: homepage(
         thememode: thememode,
         onthememodechanged: (thememode mode) {
           setstate(() { thememode = mode; });
         },
         // we can pass the index of the active theme to the homepage.
         schemeindex: themeindex,
         // where we can select a new theme in a popup menu
         // and get its index back.
         onschemechanged: (int index) {
           setstate(() { themeindex = index; });
         },
         flexschemedata: myflexschemes[themeindex],
       ),
     );
   }
 }

when you build example 4, it starts with brand blues theme. a theme that uses blue colors found in
well known web brands. the main primary blue color in the light scheme might look very familiar.

you can use the popup menu available via the listtile showing the current theme, to change theme to any
of the supplied 20 + 3 custom color schemes we added. when you change scheme, you will notice that the active
theme’s color changes are animated by interpolating from the active theme colors, to the new theme colors.
this is a very nice built-in feature when you modify the theme interactively in flutter material applications.

try some more of the themes, here is the mango mojito theme for fun.

try example 4 live on the web here

example 5 full featured demo

this example shows how you can use all the built-in color schemes in flexcolorscheme to define themes from them
and how you can define your own custom scheme colors and use them together with the predefined ones. it can
give you an idea of how you can create your own complete custom list of themes if you do not want to use any
of the predefined ones.

the example also shows how you can use the surface branding feature and how to use the custom app bar theme
features of flexcolorscheme. the usage of the true black theme feature for dark themes is also demonstrated.
using the optional windows desktop like tooltip theme is also shown.

the example includes a dummy responsive side menu and rail to give a visual presentation of what applications
that have larger visible surfaces using the surface branding look like. a theme showcase widget again shows
the theme with several common material widgets.

a sub-page is also available that show the same theme applied when opening another page that in flutter
just inherits the same theme. if you tried these examples on a device, and not on the web or a built them on
desktop, you might have noticed that the navigation bar on android devices does not always change. it is not themed to
have matching background and theme mode to match the active application theme. this example shows how this can be
fixed and that the used method remains in effect when opening a sub-page.

the same custom color schemes as in example 4, are also used in this example. they are not explained here again, please
see example 4. the full example code is not shown here, please see the code in the package folder
flex_color_scheme/example/lib/example5
for the entire example.

in this example we will also toggle the app bar theme style, the surface primary color branding strength,
tooltip style and try the true black theme toggle for dark-mode.

we will also introduce a toggle that allows us to for all the schemes use the todark computed dark schemes, instead
of the hand tuned built-in ones. you can then compare the results, the todark method does a pretty good job and can
even be tuned with a parameter if so desired. if you use this toggle on the last custom scheme, you will not see
any difference, because we already created its dark scheme with this method, the toggle just again computes the same
dark scheme.

additionally, we will include a toggle that allows us to instead of using the flexcolorscheme.totheme method, use
the standard flutter themedata.from factory to create the theme from the same color scheme definitions.
this way we can use this toggle to see and study the differences.

 :
 
 class _demoappstate extends state<demoapp> {
   // used to select if we use the dark or light theme.
   thememode thememode;
    // used to select which flexschemedata we use in our list of schemes.
   int themeindex; 
   // enum used to select what app bar style we use.
   flexappbarstyle flexappbarstyle;
   // enum used to control primary color branding on surface and background.
   flexsurface flexsurface;
   // if true, tooltip background will be light in light theme, and dark
   // in dark themes. the flutter material default and standard is the other
   // way, tooltip background color is inverted compared to app background.
   bool tooltipsmatchbackground;
   // allow toggling between normal dark mode and true black dark mode.
   bool darkistrueblack;
   // allow toggling between using the actual defined dark color scheme or 
   // try how it would look if we had not defined the dark colors, but had 
   // been lazy and just created the dark scheme from the light scheme 
   // with the todark() method.
   bool usetodarkmethod;
   // use the totheme to create themes from `flexcolorscheme`. this is
   // the preferred method when using `flexcolorscheme`. in the demo
   // you can use a toggle to see what a flexcolorscheme looks like if 
   // you the color scheme and `themedata.from` to instead create the theme.
   bool usetothememethod;
 
   @override
   void initstate() {
     thememode = thememode.light;
     themeindex = 7; // start with deep blue see theme.
     flexappbarstyle = flexappbarstyle.primary;
     flexsurface = flexsurface.medium;
     tooltipsmatchbackground = false;
     darkistrueblack = false;
     usetodarkmethod = false;
     usetothememethod = true;
     super.initstate();
   }

we define the light theme for the app, using current theme index, selected surface style and app bar style. with
the built-in 20 themes, and the three custom ones we made, we can use 23 different app themes via the setup below,
times the five surface styles and app bar variants.

the factory flexcolorscheme.light is used to define a flexcolorscheme for a light theme, from the light
flexschemecolor in the myflexschemes list, plus some other properties, like the surface and app bar style used in
this example, as well as the tooltip and true black setting for the dark theme.

   :
   @override
   widget build(buildcontext context) {
     return materialapp(
       debugshowcheckedmodebanner: false,
       title: 'flexcolorscheme',
       theme: usetothememethod
         ? flexcolorscheme.light(
             colors: myflexschemes[themeindex].light,
             surfacestyle: flexsurface,
             appbarstyle: flexappbarstyle,
             tooltipsmatchbackground: tooltipsmatchbackground,
             visualdensity: flexcolorscheme.comfortableplatformdensity,
           ).totheme

we also demonstrate how to create the same theme with the standard from color scheme themedata factory
themedata.from. the surface style works, but will not be applied as elegantly, but it works fairly ok up
to medium branding. the app bar style has no effect, nor the tooltip style.

we also have to make sure we use the same typography as the one used in flexcolorscheme, otherwise the animated
theme will show an assertion error as it cannot animate between different typography or null default
typography in the theme data.

when toggling between the standard themedata.from and the flexcolorscheme.totheme made themes from the
same colorscheme data, we can observe the differences and see some theme colors that the standard method does
not adjust to match the used color scheme. the previously mentioned article includes
a visual presentation of the differences.

         : themedata.from(
             colorscheme: flexcolorscheme.light(
               colors: myflexschemes[themeindex].light,
               surfacestyle: flexsurface,
               appbarstyle: flexappbarstyle,
               tooltipsmatchbackground: tooltipsmatchbackground,
               visualdensity: flexcolorscheme.comfortableplatformdensity,
             ).toscheme,
           ).copywith(
             visualdensity: flexcolorscheme.comfortableplatformdensity,
             typography: typography.material2018(
               platform: defaulttargetplatform,
             ),
           ),

we do the equivalent definition for the dark theme, and we add
the true black option as well. we also use the switch for colors to pass it a flexschemecolor that is either
using the predefined ones or computes them from the light flexschemecolor,

       
     darktheme: usetothememethod
       ? flexcolorscheme.dark(
          colors: usetodarkmethod
             ? myflexschemes[themeindex].light.todark()
             : myflexschemes[themeindex].dark,
           surfacestyle: flexsurface,
           appbarstyle: flexappbarstyle,
           tooltipsmatchbackground: tooltipsmatchbackground,
           darkistrueblack: darkistrueblack,
           visualdensity: flexcolorscheme.comfortableplatformdensity,
         ).totheme
       : themedata.from(
           colorscheme: flexcolorscheme.dark(
             colors: usetodarkmethod
               ? myflexschemes[themeindex].light.todark()
               : myflexschemes[themeindex].dark,
             surfacestyle: flexsurface,
             appbarstyle: flexappbarstyle,
             tooltipsmatchbackground: tooltipsmatchbackground,
             darkistrueblack: darkistrueblack,
             visualdensity: flexcolorscheme.comfortableplatformdensity,
           ).toscheme,
         ).copywith(
             visualdensity: flexcolorscheme.comfortableplatformdensity,      
             typography: typography.material2018(
             platform: defaulttargetplatform,
           ),
         ),

in dark-mode we will see some more gaps in the resulting themedata when using the standard themedata.from factory
to create the theme.

the rest of the additions in the stateful materialapp are just passing in current values and getting a new value for
it via callbacks for all our settings and their current values.

       // thememode value and change callback
       thememode: thememode,
       home: homepage(
         thememode: thememode,
         onthememodechanged: (thememode mode) {
           setstate(() { thememode = mode; });
         },
         // used theme index and change callback
         schemeindex: themeindex,
         onschemechanged: (int index) {
           setstate(() { themeindex = index;});
         },
         // used app bar style and change callback
         appbarstyle: flexappbarstyle,
         onappbarstylechanged: (flexappbarstyle style) {
           setstate(() { flexappbarstyle = style; });
         },
         // used surface branding and change callback
         themesurface: flexsurface,
         onthemesurfacechanged: (flexsurface surface) {
           setstate(() { flexsurface = surface; });
         },
         // used tooltip style and change callback
         tooltipsmatchbackground: tooltipsmatchbackground,
         ontooltipsmatchbackgroundchanged: (bool value) {
           setstate(() { tooltipsmatchbackground = value; });
         },
         // true black mode and change callback
         darkistrueblack: darkistrueblack,
         ondarkistrueblackchanged: (bool value) {
           setstate(() { darkistrueblack = value; });
         },
         // dark scheme method and toggle method callback 
         usetodark: usetodarkmethod,
         onusetodarkchanged: (bool value) {
           setstate(() { usetodarkmethod = value; });
         },
         // theme creation method and toggle method callback
         usetotheme: usetothememethod,
         onusetothemechanged: (bool value) {
           setstate(() { usetothememethod = value; });
         },
         // and pass the current flexschemedata to the  
         // homepage so we can use some info from it.
         // we use copywith to modify the dark scheme to 
         // the colors we get from toggling the switch 
         // for computed dark colors or the actual defined
         // dark colors.
         flexschemedata: myflexschemes[themeindex].copywith(
           dark: usetodarkmethod
             ? myflexschemes[themeindex].light.todark()
             : myflexschemes[themeindex].dark),
       ),
     );
   }
 }

with this example we include a side rail, it expands to a menu on web and desktop, when using a larger
canvas, it even does it in phone landscape mode. this just for demo purposes. it is here to give a better
idea and presentation of what a surface branded theme
looks like. it is of course best viewed and experienced on a tablet, or the web demo where the surface branding
theming effect is more obvious.

the homepage’s build method for this example starts by wrapping the entire page content in an annotatedregion
with a value that we get from the static helper flexcolorscheme.themedsystemnavigationbar(context). this way
we can get a system navigation bar on android phones that still uses one, that also follows the active theme’s
background color and theme mode.

   return annotatedregion<systemuioverlaystyle>(
     value: flexcolorscheme.themedsystemnavigationbar(context),
     child: ...
   );

this example starts with the deep blue sea scheme. the example image below show the new feature included from
version 1.1.0, with correctly themed system navigation bar on android devices. (some older example screenshots
further below have not been updated to include this feature.)

try example 5 live on the web here

computed dark theme

since the example allows us to toggle the dark mode from using its hand tuned predefined dark scheme colors, to the
dark scheme colors computed from the light scheme colors. let’s compare some examples.

with the above deep blue sea scheme, the computed ones are a bit more dull and muted in this example.
these screenshots are using medium surface branding, the computed dark scheme is on the right.

with some other schemes, like the aqua blue one there is only a minor difference. these screenshots
are using strong surface branding, the computed dark scheme is on the right.

the result of the todark method varies depending on how saturated the used light scheme colors are. it is possible
to tune the calculated dark scheme by modifying the whiteblend parameter it uses to blend in white to make the
dark scheme. the default whiteblend is 35%, this is normally a suitable value. for more saturated light scheme
colors try 40%, which is also used in the material design guide to convert the default red error color for light mode,
to dark mode. for light scheme color with low saturation, a white blend of 30% often also produces nice results.

branded surfaces

let us now explore the effect of branded surface colors. branded surfaces are often
associated with dark mode, but it works well with light mode too when applied delicately. below you see how
the primary color gets blended into material surface and even stronger so, into material background colors.
the screenshots below are using the medium branding strength.

you can use the toggle in the example to change from standard no branded surfaces colors, to light, medium,
strong and heavy.

the scaffold background does not receive any branding until the heavy mode. you might think that this and all
the other theming can be done by just passing the same scheme colors to the themedata.from factory. that is why
this demo allows you to flip a switch to do just that, so you can see and observe the difference between
color scheme based themes created by flexcolorscheme.totheme and themedata.from. feel free to experiment with
the live web demo where the differences are even easier to observe since you can have both versions open side by
side, in a large browser windows.

now that when we tried basic branding, we can test the tricks flexcolorscheme can do
with the appbartheme. you can easily toggle both dark and light mode app bar theme to use differently
themed backgrounds. it can use scheme primary color, the default material plain white/dark background color,
or the primary branded surface and background color versions, as well as an extra custom app bar scheme color,
which is a separate scheme color, that does not exist in flutter’s colorscheme, it thus does
not have to be any of the colors in flutter colorscheme. the predefined schemes actually use the color defined
for normal scheme secondaryvariant as the custom color used for the app bar theme.
when you make your own schemes you can do the same or use a totally not
scheme related color as the app bar’s theme color.

below you can see some different branding strengths with a background primary color branded app bar color used as well.
this example compares medium versus heavy branding. the medium choice is usually well-balanced, but light can be
subtle and nice too. if you want to make a bold statement theme, go with heavy. please note that the visual
impact of the branding also depends on how saturated the primary color is.

here are few more images of the heavy primary color branded version, when looking at some widgets as well.

true black

dark-mode is nice, but with flexcolorscheme you can go even “deeper”, go true black with the flick of a
switch. when using the true black option for dark-mode, surface, background and scaffold background are set to
fully black. this can save power on oled screens as the pixels are turned off, but it can also cause scrolling artefact
issues when pixels turn fully on and off rapidly as you scroll. you can read about this and see an example of it in
the material design guide
as well (scroll back up one heading to get to the mention of it).

if you use branded surfaces with true black mode enabled, you will notice that the branding has less of an impact,
only at strong and heavy levels will it have an impact. this is by design, to keep most surface totally or very close to
black when true black is combined with surface branding. if you really want total and true black for all surfaces
and backgrounds, then avoid combining true black mode with branded surfaces. on the other hand it still makes an even
darker theme, than normal dark theme, and it eliminates the scrolling issue since all background colored pixels are not
fully off in the strong and heavy branded true black modes.

here is an example of a branded dark theme with true black off (default and standard) and true black on,
when using heavy branding with the red red wine color scheme.

here is another difference example with the deep blue sea scheme, when using medium strength surface branding.
these screenshots are also from the newer version 1.1.0 of example 5 that includes the proper theming and branding of
system navigation bar.

behind the scenes

flexcolorscheme does not actually use the themedata.from factory with a passed
in colorscheme to make its theme. it uses the themedata factory directly with some
custom theming. it does of course define a
colorscheme that it uses for the themedata. flexcolorscheme uses color calculations for the primary color
brand blended surfaces, and for the lazy schemes that do not specify all colors in a color scheme.

used theme customizations

in addition to the primary color branded surfaces, full shaded schemes from just one primary color, true
black and app bar tricks. the returned themedata contains some opinionated modifications and theme
corrections compared to what you get if you would just use the standard themedata.from with a colorscheme.
you can still of course override the returned theme with your own theme modifications and additions, by using
the copywith method on the resulting theme.

if you want the details of what the differences compared to the standard themedata.from factory
are, here is a complete list:

• scaffoldbackground has its own color property in flexcolorscheme
  and can if so desired differ from the colorscheme.background
  color. in the branding implementation, the scaffoldbackground
  typically gets no primary branding applied, only in the heavy choice
  is there a small amount. whereas background in a flexcolorscheme
  receives the most color branding of the surface colors. this fits
  well for where the background color is used on material in widgets,
  but it does not go so well together with scaffoldbackground, which
  is the reason why it has its own color value in this implementation.
• the dialogbackgroundcolor uses the colorscheme.surface color
  instead of the colorscheme.background. the background color needed
  the strongest branding when branding is used, but this did not look
  so good on dialogs, so its color choice was changed to surface
  instead, that gets lighter branding in flexcolorscheme when it is
  used. with standard material surface colors the background and
  surface colors are the same, so there is no difference when using
  the default background and surface colors.
• the indicatorcolor uses color scheme primary instead of the
  default, which is onsurface in dark-mode, and onprimary in
  light-mode. this is just an opinionated choice and to make the
  indicator work by default on surface colored tabs.
• for toggleableactivecolor the colorscheme.secondary color is used.
  the flutter default just uses the default themedata colors and
  not the actual colors you define in the colorscheme you create your
  theme from. perhaps an oversight in flutter?
  see issue: https:github.com/flutter/flutter/issues/65782.
• flutter themes created with themedata.from does not define any color
  scheme related color for the primarycolordark color, this method
  does. see issue: https:github.com/flutter/flutter/issues/65782.
  the themedata.from leaves this color at themedata factory default,
  this may not match your scheme. widgets seldom use this color, so the
  issue is rarely seen.
• flutter themes created with themedata.from does not define any color
  scheme based color for the primarycolorlight color, this method does.
  see issue: https:github.com/flutter/flutter/issues/65782.
  the themedata.from leaves this color at themedata factory default
  this may not match your scheme. widgets seldom use this color, so the
  issue is rarely seen.
• flutter themes created with themedata.from does not define any color
  scheme based color for the secondaryheadercolor color, this method
  does. see issue: https:github.com/flutter/flutter/issues/65782.
  themedata.from leaves this color at themedata factory default this
  may not match your scheme. widgets seldom use this color, so the issue
  is rarely seen.
• background color for appbartheme can use a custom colored app bar
  theme in both light and dark themes, that is not dependent on theme
  primary or surface color. this functionality needs a custom text theme
  to be possible to implement without a context. this implementation
  does however not get correctly localized typography.

  a new feature implemented via:
  https:github.com/flutter/flutter/pull/71184 also enables this kind
  app bar theme and keep the correct typography localization. this new
  feature is (as of 28.12.2020) not yet available on channel stable.
  the first version on master could also not be enabled via themes
  only, one also had to opt in on appbar level making it difficult to
  adopt the feature. i wrote a proposal to introduce opt-in on theme
  level too: https:github.com/flutter/flutter/issues/72206
  the proposal has already been implemented. when these new features land
  in stable channel, the implementation below will be changed to use
  the new appbartheme feature, which is better than the work-around
  since we no longer need a custom text theme.

• the appbartheme elevation defaults to 0, an opinionated choice.
• like standard themedata.from color scheme themes, the
  bottomappbarcolor also uses scheme surface color. additionally,
  this color is also applied to bottomappbartheme, that like the
  app bar also gets default elevation 0.
• a deviation from themedata.from color scheme based theme’s is
  that themedata.accentcolor is set to colorscheme.primary and not to
  secondary if not otherwise defined. this is done to get an easy way
  for borders on textfield.decoration to use theme based primary
  color in dark-mode, and not accentcolor color.

  there may be a bug in the way
  inputdecorationtheme gets used by the inputdecorator. we were
  unable to define a theme that would work correctly for such a setup
  without resorting to making accentcolor equal to
  themedata.primarycolor. this definition has less of an impact
  visually to any built-in widgets than one might suspect. with the all
  the other included theme definitions we saw no other widget that used
  accentcolor. fab and toggles have their own theme and colors, so
  they still use the default expected colorscheme.secondary color
  despite this change.

• the accentcolor is made available as a separate scheme property.
  done to enable control of the outlineinputborder() active border
  color property in color scheme based themes for dark theme-mode.
• in textselectionthemedata, the standard for selectioncolor is
  colorscheme.primary with opacity value 0.4 for dark-mode and 0.12
  for light mode. here primary with 0.5 for dark-mode and 0.3 for
  light mode is used. the standard for selectionhandlecolor is
  colorscheme.primary, here we use the slightly darker shade
  primarycolordark instead, which does not have a proper color
  scheme color value in flutter standard colorscheme based themes.
• a predefined slightly opinionated inputdecorationtheme is used. it
  sets filled to true and fill color to color scheme primary color
  with opacity 0.035 in light mode and opacity 0.06 in dark-mode.
  another theme design change is done via modification of the
  themedata.accentcolor described earlier. since the used theme, like
  the default theme, does not define a border property of textfield,
  an app can still easily use both the default underline style, or the
  outline style by just specifying the default outlineinputborder()
  for the border property when outlined textfield is desired.
  if you don’t want the filled style, or the primary colored
  borders in dark-mode, you can override them back with copywith.
  for totally different border color in dark-mode you can alternatively
  specify it via the accentcolor property. which should not affect
  any other color than this border color when using flexcolorscheme
  based themes.
• the property fixtextfieldoutlinelabel is set to true by default,
  it looks better. the only reason why it is not the default in flutter,
  is for default backwards legacy design compatibility.
• button theming is applied to themedata.buttoncolor using color scheme
  primary color. the entire color scheme is passed to old button’s
  buttonthemedata and it uses texttheme set to
  buttontexttheme.primary, plus minor changes to padding and tap target
  size. these modifications make the old buttons almost match the
  default design and look of their corresponding newer buttons.
  thus, the raisedbutton looks
  very similar to elevatedbutton, outlinebutton to outlinedbutton
  and flatbutton to textbutton. there are some differences in
  margins and looks, especially in dark-mode, but they are very similar.

  this is a button style we used before the introduction of
  the new buttons with their improved defaults. it just happened to be
  very close, since the theme was based on how things looked in the material
  design guide already prior to google releasing the new flutter material
  buttons that fully implement the correct material design.

  the newer buttons are nicer, especially when it
  comes to their interactions and all the theming options they provide,
  but they are a bit verbose to theme. if you want to make custom styled
  buttons we still recommend using the newer buttons instead of the old
  ones, as they offer more customization possibilities. still, this
  theming applied to the old buttons make them look close enough to
  the new ones, to the extent that most might not even notice if
  you still use the old buttons.

• the default theme for chips contain a design bug that makes the
  selected choicechip() widget look disabled in dark-mode, regardless
  if was created with themedata or themedata.from factory.
  see issue: https:github.com/flutter/flutter/issues/65663
  the chipthemedata modification used here fixes the issue.
• the floatingactionbuttonthemedata is set as follows:

  floatingactionbuttonthemedata(
    backgroundcolor: colorscheme.secondary,
    foregroundcolor: colorscheme.onsecondary),
  

  in order to ensure the same fab style that was the default in themedata
  factory via accenticontheme in the past. if it is not defined we
  get the following deprecated warning:

  warning: the support for configuring the foreground color of 
  floatingactionbuttons using themedata.accenticontheme has been 
  deprecated. please use themedata.floatingactionbuttontheme instead. 
  see https:flutter.dev/go/remove-fab-accent-theme-dependency.
  this feature was deprecated after v1.13.2.
  

• for tabbartheme a default design that fits with surface color is
  used instead of one that fits with the app bar color.
• the bottomnavigationbarthemedata uses color scheme primary color for
  the selected item. flutter defaults to secondary color. primary color
  is a design used on ios by default for the bottom navigation bar. we
  agree and think it looks better as the default choice for apps.
• default tooltiptheme in flutter is currently a bit flawed on desktop
  and web, because it defaults to using a very small font (10 dp).
  see issue: https:github.com/flutter/flutter/issues/71429

  the default theming also does not handle multiline tooltips very well.
  the here used tooltipthemedata theme design corrects both these
  issues. it uses 12 dp font on desktop and web instead of 10 dp,
  and some padding instead of a height constraint to ensure that
  multiline tooltips look nice too.

  flexcolorscheme also includes a new boolean property
  tooltipsmatchbackground, that can be toggled to not used flutter’s
  material default that has a theme mode
  inverted background. tooltips using light background in light theme
  and dark in dark, are commonly used on the windows desktop platform.
  you can tie the extra property to used platform to make an automatic
  platform adaptation of the tooltip style if you like, or give users
  a preference toggle the tooltip style to their liking.

• the property transparentstatusbar is set to true by default and
  used to make to the appbar one-toned on android device like on ios.
  set it to false to restore default android design.

  the modification is in current implementation made with an extra call
  to systemchrome.setsystemuioverlaystyle to make the
  statusbarcolor transparent. the used implementation will be changed
  when the new appbartheme
  https://github.com/flutter/flutter/pull/71184 lands in channel stable
  that allows us to modify its annotatedregion with a passed in
  systemoverlaystyle.

  it would be nice if we could also make the system navigation button
  area on android transparent, but it does not work if we set
  systemnavigationbarcolor to a transparent color in the same call,
  it does not change it all if called during the theme definition.
  the style is doable, but requires modifying android config files, not
  possible from flutter only (as per current information).
  related issue: https:github.com/flutter/flutter/issues/69999.

  flexcolorscheme offers a helper that allows us to easily create
  and annotated region for the system navigation bar that uses
  the active color scheme and theme mode to make it at least use
  a correctly colored theme colored background for the active theme.
  see example 5 for a demo on how to use this.