> On May 31, 2016, 12:47 p.m., Martin Gräßlin wrote: > > 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 > > René J.V. Bertin wrote: > 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. > > Milian Wolff wrote: > These are two different things, why should a single class handle both? > Seperating the code makes a lot of sense. > > René J.V. Bertin wrote: > 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. > > René J.V. Bertin wrote: > 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? > > 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. > > Kai Uwe Broulik wrote: > > 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 > > 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.
> If you close and re-open the settings dialog it will load the color schemes > fresh. 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 ... - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128056/#review96083 ----------------------------------------------------------- On May 31, 2016, 10:48 a.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128056/ > ----------------------------------------------------------- > > (Updated May 31, 2016, 10:48 a.m.) > > > Review request for KDE Software on Mac OS X, KDE Frameworks and KDevelop. > > > Repository: kdevplatform > > > Description > ------- > > 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 `documentMode` which changes the look to suit use for > document tabs better, but this mode doesn't work well with KDevelop's > extensions either. > > 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. > > 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). > > > Diffs > ----- > > sublime/mainwindow_p.h abef1a7 > sublime/mainwindow_p.cpp 74ef494 > > Diff: https://git.reviewboard.kde.org/r/128056/diff/ > > > Testing > ------- > > On OS X 10.9.5 and Linux, both with fw. 5.20.0 and Qt 5.6.0 > > > File Attachments > ---------------- > > diff for kdevelopui.rc > > https://git.reviewboard.kde.org/media/uploaded/files/2016/05/30/cb07a061-aef5-42f5-bc83-68ca7ce2ce3b__patch-kdevplatform-add-style-menu-uirc.diff > 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 > > 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 > > > Thanks, > > René J.V. Bertin > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
