Provide a style-selection menu as in KDenlive (WIP)
Review Request #128056 - Created May 30, 2016 and updated
|René J.V. Bertin|
|kde-mac, kdeframeworks, kdevelop|
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
documentModewhich 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).
On OS X 10.9.5 and Linux, both with fw. (5.20.0 and) 5.22.0 and Qt 5.6.0
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
Here's an initial working draft for
KWidgetStyleSelectorwith an API inspired by
For some reason I cannot get the signal/slot connection to work when I specify the receiver which (according to a StackOverflow reply) is the safe thing to do. I did indeed have a crash once when triggering a style menu item, so eagle-eyed reviewers beware that there may be a glitch somewhere.
If this is to go into KConfigWidgets I'd prefer to expose it as a KStandardAction; advice welcome on that part.
I haven't done anything to hide the feature under Plasma for now; that's for easier testing.
Revision 2 (+199)
The current implementation undoes the effect of
-style fooon the commandline. Either don't activate any styles in
createStyleSelectionMethod, or update the
defaultStyle()function to return the style used initially.
I have no opinion which is better ATM (probably not activating a style?).
This works on OS X using the Cocoa QPA, but crashes because of a NULL
thispointer with the Xcb QPA (Linux and OS X).
For some reason the signal is never delivered when I specify
thisas the explicit receiver (regardless of whether I use a lambda or a class method as the signal handler).
Some feedback how to debug this issue would be appreciated, I'm out of ideas.