rjvbb created this revision.
rjvbb added reviewers: Frameworks, VDG.
rjvbb added projects: Frameworks, VDG.
Restricted Application added a subscriber: kde-frameworks-devel.
rjvbb requested review of this revision.

REVISION SUMMARY
  This is a split-off of my D13777 <https://phabricator.kde.org/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.

TEST PLAN
  Works as intended.
  I know it was suggested that the convenience class be committed separately. 
That will be easy enough but I see no point in reviewing separately from its 
initial application.
  
  All colours are obtained from the theme preferentially, even the text and 
window background colours. This is for consistency but also because I've seen 
rare glitches where the background colour would "lag" in open KMessageWidget 
instances when changing the theme at runtime.
  
  There's been a rumour that the `kdeglobals` store might disappear. If  and 
when that happens this code will have to be adapted but I don't see a reason to 
stop using the file now already.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13899

AFFECTED FILES
  src/CMakeLists.txt
  src/kmessagewidget.cpp
  src/kthemesettings.cpp
  src/kthemesettings_p.h

To: rjvbb, #frameworks, #vdg
Cc: kde-frameworks-devel, michaelh, crozbo, firef, ngraham, bruns, skadinna, 
aaronhoneycutt, mbohlender

Reply via email to