<table><tr><td style="">ngraham added a comment.
</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/D13777">View Revision</a></tr></table><br /><div><div><p>Thanks for your continued work on this. I continue to believe that in order to move forward, it needs to be broken up into separate atomic commits:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">One to add a color parsing function to <tt style="background: #ebebeb; font-size: 13px;">KWidgetsAddons</tt> so other local clients can use it</li>
<li class="remarkup-list-item">Another to adopt that functionality in <tt style="background: #ebebeb; font-size: 13px;">KMessageWidget</tt></li>
<li class="remarkup-list-item">A third one to add the background brightness introspection/calculation functionality</li>
<li class="remarkup-list-item">Fourth and fifth ones to adopt the brightness processing in <tt style="background: #ebebeb; font-size: 13px;">KMessageWidget</tt> as well as in the Kirigami <tt style="background: #ebebeb; font-size: 13px;">inlineMessage</tt> widget</li>
</ul>

<p>Why all this work? Three good reasons:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item"><strong>Principle:</strong> commits should be atomic.</li>
<li class="remarkup-list-item"><strong>Practicality</strong>: the first two commits are non-controversial and will probably be committed quickly, and then we don't have to gate them on the result of a discussion about the more controversial brightness matching part.</li>
<li class="remarkup-list-item"><strong>Consistency</strong>: if we change the visual style of <tt style="background: #ebebeb; font-size: 13px;">KMessageWidget</tt>, we need to make the same change in Kirigami's <tt style="background: #ebebeb; font-size: 13px;">inlineMessage</tt> or else we're missing the point of why the original change was made in the first place--to keep consistency between the two implementations. A reasonable amount of consistency between Kirigami and QWidgets-based Desktop apps is important to avoid generating the perception that Kirigami is a "mobile first" framework that just produces "big dumb phone apps on the desktop." We want people to enthusiastically adopt Kirigami for desktop apps, and that won't happen if the same control looks and feels needlessly different from the QWidget version.</li>
</ul></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/D13777">https://phabricator.kde.org/D13777</a></div></div><br /><div><strong>To: </strong>rjvbb, ngraham, Frameworks<br /><strong>Cc: </strong>cfeck, kde-frameworks-devel, michaelh, ngraham, bruns<br /></div>