Future Features

This chapter lists potential new features. They may be planned or even just idea phase future features. They are listed as polls in the repo discussions. Feel free to add additional ideas and requests there, and to up or down vote existing ones.

When features are being worked on, you can find them as tasks in the repo project.

Proposed Features#

• #66 Themes Playground, GUI for item size modifiers for BottomNavigationBar

• #67 Themes Playground, GUI for item size modifiers for NavigationBar

• #68 Themes Playground, GUI for item size modifiers for NavigationRail

• #69 Add CupertinoTheme support

• #126 Add Squircle (hyper ellipses as border radius) as a border shape option

  • This will likely be added when Flutter supports the correct iOS squircle shape. Currently, Flutter does not have the correct Squircle shape support built-in. Adding a custom algo may have performance implications if it is not implemented in a way that is also supported by the GPU. Cupertino/iOS widgets in Flutter should use the Squircle shape, but they do not, never have. This is one reason why they look a bit off.

• #127 Add a theme extension to store the tonal palettes used to generate a seed generated ColorScheme

  • This would make all the colors in the tonal palettes available in both the light and dark theme mode.

• #128 Add system font scaling to the playground, for testing purposes only

• #129 Add LTR/RTL UI toggle for testing purposes in the Theme Playground

• #130 Add images as color sources for themes in the Themes Playground

Long term#

Build a totally new Themes Playground, that is more designer and team work friendly. Maybe a "Pro" version of the Themes Playground? The current version is still after all "only" a developer's FlexColorScheme API configurator. The Playground is not really a part of the package, but more like a bonus feature. It might become its own app. You can find some more info about that here.

Out of Scope#

Serialization of FlexColorScheme#

Including built-in serialization of FlexColorScheme, and its key classes has been suggested. I consider FlexColorScheme to be functionally on a level similar to ThemeData and ColorScheme. Therefore, it should not cover serialization of itself. Serialization has to deal with a lot of potential failure points. We think it should not have to be a concern in this type of component. There is no plan to add it.

Our recommendation for saving the state of a FlexColorScheme is to include values for its settings that you use in your implementation in other models in your application, like an "AppSettings" model or similar.

You probably serialize and store such data already, perhaps with shared preferences, hive, isar, get_storage or some other solution. Include the values you need for your FlexColorScheme implementation in your stored settings and then use those values to restore your FlexColorScheme configuration and theme. This way, your implementation also remains in control of what it needs to store and restore.

From version 4.0.0, a simple approach using the architecture introduced via the Flutter "skeleton" template in Flutter version 2.5 was used together with Shared Preferences and Hive to persist and load FlexColorScheme on start. This is just one example, other implementations together with Riverpod, Provider, Flutter Bloc, GetX etc., and completely different local persistence packages work well too.