KColorScheme is in an odd place where it is difficult for end users who want to make colorschemes, but it doesn't have the right amount of granularity for designers. It's also quite annoying to make use of all of its color roles since you have to make instances of KColorScheme or KStatefulBrush. Meanwhile, QPalette is already built into Qt Widgets and Qt Quick Controls, so we tend to use that instead. This feeds into the difficulty for end users because it's not clear when, where or why some color roles won't have an effect. `Kirigami.Theme` (which uses KColorScheme through qqc2-desktops-style) is a big exception since it's actually pretty convenient to use in QML, but it still has the granularity issue.
KColorScheme2 tries to fix these problems by giving developers/designers the ability to have as much granularity as they want and tries to make color scheme creation easier for end users by requiring less effort to create a functional color scheme. Maybe App developers/designers could be able to create a color scheme for parts of their application that would use a custom palette too.
Basically, KColorScheme2 is a system for managing multiple QPalettes. You can have a QPalette for each combination of context and style. Changing the context or style of a widget changes the QPalette of that widget. This makes it much more convenient to use than KColorScheme. A potential downside is higher RAM usage since every single application could have multiple QPalettes. Perhaps there are ways to mitigate or even stop that from being an issue?
I have some concerns that this won't really be a major improvement over KColorScheme unless parts of this end up in Qt itself. Otherwise, we can still use the new features in our QStyle and QQC2 style, but they won't be as widely used as I'd like them to be.
## Contexts
- Default
- Possibly many kinds of contexts (window header area, main sidebar, main view area, etc.)
- Maybe make it extensible by app devs?
## Styles
- Light
- Dark
- Maybe make it extensible by app devs?
- End users can select Light or Dark via settings, so have a way to get the current Style and the Style chosen by the user for their system.
## Definition/Inheritance Behavior
In order to prevent the creation of color schemes from becoming too complex for end users, they shouldn't need to customize every single Context, Style, ColorGroup and ColorRole to get a usable color scheme.
- An undefined or incomplete Default Context will get missing parts from the platform theme.
- Diagram showing where default QPalette colors come from: {F9956179}
- The default QPalette will be set by our platform theme, which will use the system color scheme
- When there is no system color scheme with a complete Default Context, use hardcoded colors to fill the missing parts.
- It would probably be a good idea if there were hardcoded fallback colors for both the Light and Dark styles so that Light and Dark will always have something usable.
- All Contexts inherit from the Default Context by default.
- All Styles inherit from the same Style in the Default Context by default.
- ColorGroups are handled the way QPalette normally handles them by default.
- I think this means Inactive is the same as Active and Disabled is just 50% opacity by default.
- If some or no ColorRoles are defined for a section, get the missing parts via inheritance.
- Ignore invalid ColorRoles.
- Use inherited/default QPalette values when values are invalid.
- Each section can explicitly define a context, style and color group to inherit from.
- If an invalid Context, Style or ColorGroup is explicitly inherited from, use default inheritance for the invalid type.
Originally, I thought of having Styles at the top level since I thought of Light and Dark as being higher level than Contexts. However, I think it's more likely that app developers will want to choose different Styles based on the Context. The fact that Styles go under Contexts shouldn’t matter to end users unless they want to manually edit color scheme files.
**Maybe:**
- Allow new Contexts and Styles to be declared in the color scheme file?
## Data Organization
Each section could be structured something like this:
```
[Context][Style][ColorGroup]
Inherits=Context,Style,ColorGroup
ColorRole=uint8,uint8,uint8,uint8
# alpha is optional
```
A more realistic example:
```
[SideBar][Dark][Disabled]
Inherits=MainView,Dark,Disabled
Base=0,0,0
Text=255,255,255,127
```
## API
- Is it possible to make it work using static functions? It would be very convenient if we could do something like `KColorScheme2::setContext(SomeContext, widget)` or `KColorScheme2::setStyle(Dark, widget)`, to set the palette for a widget and have the palette propagate to children of the widget. This is sort of similar to `Kirigami.Theme.colorSet: Kirigami.Theme.View` in QML.
- Is it possible to make it work for Qt Widgets and QQC2/Qt Quick? Maybe as long as a QObject has a `palette` property or `palette()` and `setPalette()` functions, it can work with the KColorScheme2 functions?
## Example Usecases
- Gwenview
- Rather than making a custom always dark QPalette for fullscreen mode, just switch to the Dark Style when in fullscreen mode.