[KDE/Mac] Review Request 128056: Provide a style-selection menu as in KDenlive (WIP)

Tue May 31 14:14:34 UTC 2016

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20160531/d8f1a760/attachment.html>