Review Request 128056: Provide a style-selection menu as in KDenlive (WIP)

[Milian Wolff]

> On May 31, 2016, 8:51 a.m., Milian Wolff wrote:
> > -2
> > 
> > kdevelop should use the global widget style. if you don't want that, change it via systemsettings
> 
> Aleix Pol Gonzalez wrote:
>     Well, it's not far-fetching to understand that on non-plasma systems this KCM will be hidden or unavailable.
>     Linux's Skype does something like that too, FWIW.
> 
> René J.V. Bertin wrote:
>     Exactly. It's even been claimed that applications on non-plasma systems should just use whatever is available there, and users should put up with any subsequent limitations ... or else feel free to "break things" if that doesn't work for them and/or they prefer "fugly" (meaning non-native) looks-and-feels.
>     
>     Anyway, the default is to use the global style (there's "default" style entry in the menu for that, too). I did consider adding the code in #ifdefs but didn't because I realised that KDevelop, digiKam and Kdenlive are all applications users are likely to spend lots of time with and have occupying a good part of the (a) screen. That might change their preference for things like widget style or colour theme (cf. the recent dark colour palette that was added to Kate).
> 
> René J.V. Bertin wrote:
>     Oh, and another thing with using `systemsettings`: it depends on being able to use the KDE platform theme plugin. I don't know about MS Windows, but on OS X that requires patching Qt.
>     In-application style switching is possible just about everywhere.
> 
> Martin Gräßlin wrote:
>     > kdevelop should use the global widget style. if you don't want that, change it via systemsettings
>     
>     I agree with Milian that on platforms where systemsettings is available (aka Plasma), we don't want that in every application. So from an application point of view I would suggest to bind whether the menu gets shown to a key which can be set by the QPT plugin. That way we can add the menu where it makes sense, but also hide by default in e.g. Plasma.
> 
> René J.V. Bertin wrote:
>     Not in every application, no. I'm not even sure if that's necessary in non-plasma environments (or else it would really plead for a solution to set a system or session wide default even with stock Qt).
>     But would you want to make it off-limits (under Plasma) to applications that already do? Or oblige them to keep rolling their own solution?

I really don't want this option to be available in a plasma session. I would even go as far and say that this should not be available in GTK either but I don't care that much. If you want to hack it in for other platforms, OK but then make sure it's not available in a plasma session. Also, push the code into e.g. kconfigwidgets and share it between the applications that want this behavior.


- Milian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128056/#review96077
-----------------------------------------------------------


On May 31, 2016, 8: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, 8: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-frameworks-devel/attachments/20160531/3cd6832c/attachment-0001.html>