This is a split-off of my D13777 WIP project (for lack of a better word).
KMessageWidget used to use the highlight colour for informational messages and hardcoded colours for the other 3 types. This was never ideal but acceptable because a user-defined colour was used for the most common message type and commonly accepted colours for the other types (orange for warnings, red for errors).
This patch changes that: all colours are obtained from the current theme, if possible. It also reverts to using the highlight colour as a fallback for information messages.
To obtain the theme colours a utility class KThemeSettings is introduced that provides a QSettings-based interface to the colour definitions in theme files or the global settings store:
- if an application used the KColorSchemeManager it will have a KDE_COLOR_SCHEME_PATH property pointing to the actual theme definition file; colours will thus be read from there
- if the property is not set, the class will attempt to get the definitions from the global settings store
- if that fails too, a fallback QColor value will be returned.
The ctor takes a group argument for convenience, allowing to open the group of interest directly with all existence checking and error handling done inside the class.
The readRGB() method is named to indicate the fact it returns an RGB triplet via a QColor instance.