Hi all,
in thinking about this bug
https://bugs.kde.org/show_bug.cgi?id=336246
i started to wonder, what is the proper-proper solution?
or better, what is actually the real problem behind the bug?
in the end, we want to know where a widget is, in order to decide what colors
to use.
the partly inverted palette of the lockscreen design exposes this problem, but
also some themes like oxygen that have dask background usually and light
background for buttons.
Enter PlasmaCore.ColorContext
it's an import in core, and advertises itself as an "attached property"
with this we can:
say that all its chidren are of a certain context, like "button" or
"complementary"
then anywhere there will be available an attached property, as ColorContext,
so like:
PlasmaCore.ColorContext {
group: PlasmaCore.Theme.Complementary
PlasmaComponents.Label {
text: "foo"
color: ColorContext.textColor
}
}
and the color will be automagically correct
same thing for coloring svgs
and if this is done directly in components, magic++
I think this can be introduced slowly, so 5.0 would have only the colorContext
class available and manually used just in the lockscreen components
to do something really pretty, if this had been tought of some months ago, I
would really have liked to get rid of all the color properties in Theme
(textColor, buttonTextColor and so on), but i won't do it, because is too late
and would risk to break stuff, so those properties will still be available but
kinda legacy and really correct only when you have some reason to fix a color
independent from the context (so would make kinda sense)
what i would instead do, is slashing the enum for colors, removing
ButtonTextColor etc(that luckily is not really used directly outside plasma
components, so easy to change), since now we have
Theme::color(ColorRole, ClorGroup) that can be used in the properties, that
won't alter their behavior
this would also make it less messy to add other classes of color in the future
(like at some point the vdf wanted to introduce colors for negative and
positive feedback, luckily available in kcolorscheme)
--
Marco Martin
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
