> On May 31, 2016, 10: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? > > Milian Wolff wrote: > 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.
I can take care of a class that can be pushed into KConfigWidgets (following Aleix's suggestion), but someone else will have to provide the proper hook(s) to deactivate the use of that class under Plasma. All I can do is couple it to the existence of `KDE_FULL_SESSION`, which doesn't seem very satisfactory. - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128056/#review96077 ----------------------------------------------------------- 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
