This is an idea (or opinion if you want) I got as a result of a recent change in KWidgetsAddons that introduced what I think is a regression for which I am proposing a solution (https://phabricator.kde.org/D13777).

KMessageWidgets have always used the highlighting colour from the receiving widget for informational messages, and hardcoded colours for the other categories because as a Tier1 framework it cannot use KConfig.

That never gave me pause because the resulting colours were either under my control or acceptable. Notably, the warning and error messages had orange and red background colours respectively. Those are the commonly accepted standard colours for that purpose (cf. car dashboards).

Then KMessageWidget was aligned to look more like the equivalent Kirigami widgets - a wrong move IMHO because if anything was to align it would have been Kirigami, being the newcomer. As a result, all colours are now hardcoded, and all of a sudden I was getting clear blue backgrounds on the most common messages I get.

I tuned my own visual style and am very strict about keeping blue out of it as much as I can (to me, blue is for a different sensory modality - music!) so this felt like a visual insult.

In an initial attempt I followed the following reasoning.
- orange and red are fine for warning and error messages respectively; no need for change there
- information messages are not unlike the messages given by tooltips, so they could use the tooltip background colour from the widget (or application) palette
- positive messages are (probably, no documentation for them) for positive feedback, so they could use the highlight background colour from the palette.

I like the result that gives, including the fact that in certain themes informational messages will end up with a grey background. But this was rejected under review.

So my current solution implements a basic access to the global settings store (kdeglobals; it has been suggested I make this access available to other classes) and replaces the 4 hardcoded colours with the current theme's definition of those colours:

Window: ForegroundPositive for Positive
Window: ForegroundActive for Information
Window: ForegroundNeutral for Warning
Window: ForegroundNegative for Error

The final background colour also depends on the widget's background colour, and a (a priori) hardcoded alpha value.

I see a few issues with this approach, and I am now coming to the idea I'd like to propose here:

1. these are foreground, i.e. text colours. Using *four* of them as background colours may put certain existing themes in a problem situation because they made colour choice(s) that are unhappy with the new use of these colours. My own palette has very similar reddish colours for active text and negative text, for instance (active text being the darker of the two). I don't think there's any reason why this would be (or was) a bad idea. As stated in kcolorscheme.h;

* Foreground colors are suitable for drawing text or glyphs (such as the
* symbols on window decoration buttons, assuming a suitable background
* brush is used), and should never be used to draw backgrounds.

2. a single hardcoded alpha value may not be able to give appropriate shading of all four colours for all themes. My own palette and eyes require a different alpha for the information colour for instance (based on the psychometric/perceived brightness of the selected colour in this case).

This leads me to think that a new basic access to kdeglobals paves the way to exposing a few more existing categories (colour roles) to the colour themes. KColorScheme already has the equivalent four BackgroundRole categories, {Positive,Active,Neutral,Negative}Background. Themes currently only define BackgroundAlternate and BackgroundNormal, but could easily provide custom colours for the other roles as well.

Exposing these roles for theming would address the two issues above. It would also make it possible to define better greyscale themes which reduce the use of candy colours to a maximum.