<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/128056/">https://git.reviewboard.kde.org/r/128056/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On May 31st, 2016, 12:47 p.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I suggest to look at https://api.kde.org/frameworks/kconfigwidgets/html/classKColorSchemeManager.html which does something similar just for color schemes. Might make sense to have the API structured very similar</p></pre>
</blockquote>
<p>On May 31st, 2016, 12:59 p.m. CEST, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes, that would make sense. Alexander Zhigalin already contacted me about possible intersection with his work on KColorScheme. I thought he meant he was trying to add such a class but that appears not to be the case. Almost a pity, because it seems you could have a single class that handles both aspects.</p></pre>
</blockquote>
<p>On May 31st, 2016, 2:20 p.m. CEST, <b>Milian Wolff</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">These are two different things, why should a single class handle both? Seperating the code makes a lot of sense.</p></pre>
</blockquote>
<p>On May 31st, 2016, 3:10 p.m. CEST, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Both make sense to me. They're 2 different things, sure, but those things are related because aspects of an application's look and feel. Applications that want to be able to modify the one probably will want that for the other too, so it'd be efficient to have a single class that can put up, say, a submenu with Style and Colour submenus.</p></pre>
</blockquote>
<p>On May 31st, 2016, 3:21 p.m. CEST, <b>René J.V. Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Martin: isn't KColorSchemeManager more like a KColorSchemeSelector, despite the fact it can return something abstract like a QAbstractItemModel? Looking at the code I don't see how it would refresh the internal list/model in case the user installs or removes colour schemes, correct?
Do we agree that a KWidgetStyleManager or KWidgetStyleSelector class would not return a model (at most a QStringList) and that the preview feature would be nice but a bit too expensive?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Side note: the Oxygen demo app makes a great widget style explorer (much better than the thingy in the style KCM) and should really be made available as a utility dedicated to that purpose.</p></pre>
</blockquote>
<p>On May 31st, 2016, 4:04 p.m. CEST, <b>Kai Uwe Broulik</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Looking at the code I don't see how it would refresh the internal list/model in case the user installs or removes colour schemes</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">And why should it. If you close and re-open the settings dialog it will load the color schemes fresh. I agree that "Manager" might not be the best name.</p></pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">If you close and re-open the settings dialog it will load the color schemes fresh.</p>
</blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes, but what if you use the class to put up a menu with the installed colour schemes? Not that schemes or styles are (un)installed so frequently that it would be justified to complicate the code a lot just to keep the menu uptodate ...</p></pre>
<br />
<p>- René J.V.</p>
<br />
<p>On May 31st, 2016, 10:48 a.m. CEST, René J.V. Bertin wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for KDE Software on Mac OS X, KDE Frameworks and KDevelop.</div>
<div>By René J.V. Bertin.</div>
<p style="color: grey;"><i>Updated May 31, 2016, 10:48 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdevplatform
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I filed a bug report recently that raises an issue about the QTabBar widget for the tabbed document interface (https://bugs.kde.org/show_bug.cgi?id=363473). On OS X, that widget is rendered like the native tab bar widget that should only be used in dialogs and comparable views where the number of tabs is preferably fixed and limited. There are also other rendering issues which probably stem from presumptions KDevelop makes about the tab layout in the extensions it implements.
Qt does provide a <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">documentMode</code> which changes the look to suit use for document tabs better, but this mode doesn't work well with KDevelop's extensions either.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">For lack of a better solution or workaround I would thus like to explore the idea to provide a widget style picker, like KDenlive does (presumably not without reason either). The underlying idea is that it allows users to find an style that works better for them if they feel a reason to do so. This option works regardless of whether a platform theme plugin is available.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">For now the patch is a proof-of-concept and work in progress. It is still lacking a mechanism to make the style choice persistent across restarts; I think I'll need a hand in determining how to do that correctly (it should be a global setting, not a session-specific setting I think).</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">On OS X 10.9.5 and Linux, both with fw. 5.20.0 and Qt 5.6.0</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>sublime/mainwindow_p.h <span style="color: grey">(abef1a7)</span></li>
<li>sublime/mainwindow_p.cpp <span style="color: grey">(74ef494)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/128056/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">File Attachments </h1>
<li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2016/05/30/cb07a061-aef5-42f5-bc83-68ca7ce2ce3b__patch-kdevplatform-add-style-menu-uirc.diff">diff for kdevelopui.rc</a></li>
<li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2016/05/30/543bffc8-26fd-44f8-8bd8-372a24c9b01f__Screen_Shot_2016-05-30_at_15.47.14.png">This screenshot shows where the menu item appears with the kdevelopui.rc patch in another attachment. This KDevelop instance was running with my platform theme plugin and my OS X palette and config for the QtCurve style. Only the UI fonts change when the p</a></li>
</ul>
</td>
</tr>
</table>
</div>
</body>
</html>