<table><tr><td style="">rjvbb created this revision.<br />rjvbb added reviewers: Frameworks, VDG.<br />rjvbb added projects: Frameworks, VDG.<br />Restricted Application added a subscriber: kde-frameworks-devel.<br />rjvbb requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D13899">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>This is a split-off of my <a href="https://phabricator.kde.org/D13777" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D13777</a> WIP project (for lack of a better word).</p>

<p>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).</p>

<p>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.</p>

<p>To obtain the theme colours a utility class <tt style="background: #ebebeb; font-size: 13px;">KThemeSettings</tt> is introduced that provides a QSettings-based interface to the colour definitions in theme files or the global settings store:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">if an application used the <tt style="background: #ebebeb; font-size: 13px;">KColorSchemeManager</tt> it will have a <tt style="background: #ebebeb; font-size: 13px;">KDE_COLOR_SCHEME_PATH</tt> property pointing to the actual theme definition file; colours will thus be read from there</li>
<li class="remarkup-list-item">if the property is not set, the class will attempt to get the definitions from the global settings store</li>
<li class="remarkup-list-item">if that fails too, a fallback QColor value will be returned.</li>
</ul>

<p>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.<br />
The <tt style="background: #ebebeb; font-size: 13px;">readRGB()</tt> method is named to indicate the fact it returns an RGB triplet via a QColor instance.</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Works as intended.<br />
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.</p>

<p>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.</p>

<p>There's been a rumour that the <tt style="background: #ebebeb; font-size: 13px;">kdeglobals</tt> 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.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R236 KWidgetsAddons</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D13899">https://phabricator.kde.org/D13899</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>src/CMakeLists.txt<br />
src/kmessagewidget.cpp<br />
src/kthemesettings.cpp<br />
src/kthemesettings_p.h</div></div></div><br /><div><strong>To: </strong>rjvbb, Frameworks, VDG<br /><strong>Cc: </strong>kde-frameworks-devel, michaelh, crozbo, firef, ngraham, bruns, skadinna, aaronhoneycutt, mbohlender<br /></div>