<table><tr><td style="">amhndu updated this revision to Diff 44342.<br />amhndu 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/D15645">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>kcolorschemedemo.cpp does not actually seem to build an executable.</p></blockquote>

<p>It should build <tt style="background: #ebebeb; font-size: 13px;">kcolorschemedemo</tt> in <tt style="background: #ebebeb; font-size: 13px;">kconfigwidgets/bin</tt> (also has <tt style="background: #ebebeb; font-size: 13px;">kcolorschemedemo</tt> target in make)</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Regardless, wouldn't it make sense to expose this new feature in the existing Settings → Color Theme menu? Or are you planning to do that in another patch?</p></blockquote>

<p>Yes, that would require a patch for each application that'd use it. The problem is that with the new menu,<br />
we need a way to distinguish between the reset action and the other actions.<br />
So that applications don't just save the current system scheme in their config, if they did,<br />
the application would still use the previous scheme even after the user changed the system scheme. While resetting should mean the app<br />
should now be following the scheme, just as before setting anything manually.<br />
The new variant has the index as the data instead of the path, this allows checking the index's DisplayRole<br />
and the action's text to distinguish the reset, this is admittedly not a very good solution.<br />
I couldnnott think of anything else that's simple and wouldn't require much change in client code.<br />
What could be an alternative solution here ?<br />
I've thought of creating a subclass of KActionMenu which has two signals - one for reset and one for setting a scheme and returning that,<br />
but that would again require modifying applications to use these signals instead.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>instead of a custom variant, what about creating new versions of the createSchemeSelectionMenu functions that take flags instead?</p></blockquote>

<p>I created a new variant since this isn't compatible with the other overload, as explained above.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R265 KConfigWidgets</div></div></div><br /><div><strong>CHANGES SINCE LAST UPDATE</strong><div><a href="https://phabricator.kde.org/D15645?vs=44279&id=44342">https://phabricator.kde.org/D15645?vs=44279&id=44342</a></div></div><br /><div><strong>BRANCH</strong><div><div>system-default</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D15645">https://phabricator.kde.org/D15645</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>src/kcolorschememanager.cpp<br />
src/kcolorschememanager.h<br />
src/kcolorschememanager_p.h<br />
tests/kcolorschemedemo.cpp</div></div></div><br /><div><strong>To: </strong>amhndu, Frameworks, broulik, cfeck, elvisangelaccio, ngraham, pino<br /><strong>Cc: </strong>pino, ngraham, broulik, kde-frameworks-devel, michaelh, bruns<br /></div>