| broulik |
| Kirigami |
In some scenarios, some applications need certain areas with completely custom
palettes, for instance if a piece of ui is on top of an image it may make
sense that hierarchy uses whatever the dominant colors of such image are.
in the scenario of a Custom color set, the qml code would look like this:
Item {
Kirigami.Theme.inherit: false Kirigami.Theme.colorSet: Kirigami.Theme.Custom Kirigami.Theme.textColor: "#af2352" Kirigami.Theme.backgroundColor: "#124523" ...
}
piece with a custom set in the gallery
| No Linters Available |
| No Unit Test Coverage |
note that some pieces of breeze controls can't have a custom color as breeze uses kcolorscheme directly for them, so they can only be read from kdeglobals (mouseover effect for buttons doesn't work as well in the current colors kcm preview for this reason)
| src/kirigamiplugin.cpp | ||
|---|---|---|
| 172 ↗ | (On Diff #35517) | What's this? |
| src/libkirigami/basictheme.cpp | ||
| 133 | Probably prints warnings for themes that don't have this? | |
| src/libkirigami/platformtheme.cpp | ||
| 314 ↗ | (On Diff #35243) | Can this lead to issues with non-deterministic setting of properties? Ie. say Kirigami.Theme.textColor is evaluated before Kirigami.Theme.colorSet: Kirigami.Theme.Custom? |
| src/libkirigami/platformtheme.h | ||
| 79 | Do they need a RESET? | |
| 237 | Where is this used? | |
| src/kirigamiplugin.cpp | ||
|---|---|---|
| 172 ↗ | (On Diff #35517) | gah, sorry, remains of old attempts |
| src/libkirigami/platformtheme.cpp | ||
| 314 ↗ | (On Diff #35243) | it would work fine, as writing to color properties always works... the only thing i can think about to make it work in a more predictable way is: duplicate every setter, with setCustomTextColor etc (so setTextColor to be used only by implementations), and store all the custom colors in different members, then textColor() would be return colorSet == custom ? d->customTextColor : d->textColor (then a reset method could be implemented |
| src/libkirigami/platformtheme.h | ||
| 79 | perhaps... i wouldn't know how to implement one with the current architecture | |
| 237 | crap, another remain of old approach :) | |