Config-driven theming (no hardcoded colors)
Gregori Vorontsov
TLDR:
1) Only pull colors from the config. 2) Expose more colors. 3) No strange hardcoded colors we can't change.
Longer description:
Some of us need light mode to reduce eye strain, others want to create all sorts of custom themes. Why let us change 90%, only to disappointingly find out that the remaining 10% is locked?
You as the developer should not have to support any custom themes, period. Let us the users take care of it, only you have to expose the values that make this possible. We already have a tailwind config — so let's use it consistently, not a little bit here and a little bit there.
Replace current hardcoded colors and map them in the config (perhaps with # comments).
Clean and simple, future-proof theming with minimal effort. All maintenance effort on the community, not the developers.
You as the developer get one clean central config that stores all the used colors, we as the users get a central config to customize. Let everything outside of it remain unsupported & beyond scope. Only expand the current scope to not be so limited.
The biggest issue is hardcoded light icons that do not work well on a custom light theme. Selection and selection highlight colors should be exposed as the default won't work well on every setup (again, light mode). Same for the default curve color.