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.
- 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.
- This would make all the colors in the tonal palettes available in both the light and dark theme mode.
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
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.