[KDE/Mac] Review Request 126198: [OS X] adaptations for the KdePlatformTheme

René J.V. Bertin rjvbertin at gmail.com
Mon May 16 13:21:57 UTC 2016

This is an automatically generated e-mail. To reply, visit:

(Updated May 16, 2016, 3:21 p.m.)

Review request for KDE Software on Mac OS X, KDE Frameworks, Plasma, and Valorie Zimmerman.


I'd been meaning for a while now to update this RR, since I wasn't getting any feedback on it.

Now that the platformtheme has been moved, what do you propose we do with the OS X platform theme?

I saw that one of the justifications for the move was a dependency on Plasma library/ies, but I don't see any such dependencies in the latest version before the move (commit 07548ac1fe7a7fb31a941473911e982fb623c07d).

It's a pity that this discussion fell into oblivion, I'd argue (or have argued) that
- there's sufficient reason to have a dedicated OS X platform theme because there are apparently no other feasible solutions to allow KF5 applications to benefit from KDE's font and colour palettes, regardless of whether that is with the native widget style (`"macintosh"`) or with another style. It should go without saying that applications designed with the automatic existence of specific fonts (and colour) palettes in mind will look better when they can use those fonts (and colours).
- applying this patch to `plasma-integration` to provide the Mac platform plugin via that package makes little sense because there's no Plasma (session) to integrate with. There *are* components in Plasma that make sense outside of Plasma sessions but they don't justify an interpretation where the `plasma-integration` package is for integrating Plasma with the host. Also, the package has dependencies on X11 and Wayland that would have to be removed on OS X.
- given the 2 above points, I'd suggest (have suggested) to keep the platform plugin where it is for OS X especially if the other components of the `framework-integration` framework are still relevant.

What bothers me a bit is that this move makes it much less trivial to maintain the Mac platform theme as a special version of the standard platform theme, subclassing its classes. Or maybe we can safely let the platform plugins diverge from this point? Would I have to revert all of my subclassing effort or would it be better to leave that aspect as is for the time being because it should make it easier to "sync" with the plasma platform theme?

Repository: frameworkintegration


The KdePlatformTheme plugin can be enabled on OS X with a minimal patch to Qt5; all that is required is to include the `qgenericunixservices` and `qgenericunixthemes` components in the build, and to append `"kde"` to the list returned by `QCocoaIntegration::themeNames()` for instance under the condition that `KDE_SESSION_VERSION` is set to a suitable value in the environment.

This will allow KF5 and Qt5 applications to use the theme selected through KDE if FrameworkIntegration is installed and KDE_SESSION_VERSION is set, which seems like a sufficiently specific set of conditions that is easy to avoid by users who prefer to use the Mac native theme.

While requestion the KDE theme is also possible through `-style kde` or `env QT_STYLE_OVERRIDE=kde` the use of the KdePlatformTheme plugin appears to be the only way to get the full theme, including the font and colour selection. In my opinion it is above all the font customisation which is a very welcome feature for Qt/Mac; by default Qt applications use the default system font (Lucida Grande 13pt or even 14pt) throughout. This is a good UI font, but not at that size (and most "native" OS X applications indeed use a range of smaller sizes, depending on role.

It does have introduce a number of regressions, which the current patch aims to address. The most visible and problematic of these regressions is the loss of the Mac-style menu bar and thus of all menu items (actions).

The fix is straightforward : on OS X (and similarly affected platforms?), an instance of the native Cocoa platform theme is created through the private API, and used as a fallback rather than immediately falling back to the default implementations from `QPlatformTheme`. In addition, methods missing from (not overridden by) `KdePlatformTheme` are provided on OS X and call the corresponding methods from the native theme. It is this change which restores the menubar and even the Dock menu functionality.
One minor regression remains but should be easy to fix (elsewhere?): the Preferences menu loses its keyboard shortcut (Command-,).

Given the fallback nature of the native platform instance I have preferred to print a warning rather than using something like `qFatal`, above all because the message printed by qFatal tends to get lost on OS X. I can replace my use of `qWarning` with a dialog giving the choice between continuing or exiting the application - code that would be called in the menu methods because only there is it certain that the application actually needs a menubar.

In line with experience and feedback from the KDE(4)-Mac community I have decided to force the use of native dialogs rather than the ones from the KdePlatformPlugin.

In addition I set the fallback value for `ShowIconsOnPushButtons` to false in line with platform guidelines, and ensure that the autotests are not built as app bundles.

Diffs (updated)

  src/platformtheme/CMakeLists.txt 23f590e 
  src/platformtheme/kdemactheme.h PRE-CREATION 
  src/platformtheme/kdemactheme.mm PRE-CREATION 
  src/platformtheme/kdeplatformtheme.h 97d09df 
  src/platformtheme/kdeplatformtheme.cpp 80dbcb7 
  src/platformtheme/kfontsettingsdata.h 4b92c7d 
  src/platformtheme/kfontsettingsdata.cpp b0a4bbf 
  src/platformtheme/kfontsettingsdatamac.h PRE-CREATION 
  src/platformtheme/kfontsettingsdatamac.mm PRE-CREATION 
  src/platformtheme/khintssettings.h ec064d3 
  src/platformtheme/khintssettings.cpp 8adf6c5 
  src/platformtheme/khintssettingsmac.h PRE-CREATION 
  src/platformtheme/khintssettingsmac.mm PRE-CREATION 
  src/platformtheme/main_mac.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/126198/diff/


On Mac OS X with Qt 5.5.1, KF5 frameworks 5.16.0 and QtCurve git/head.

I have not verified to what extent my use of a private `QGuiApplication` API links builds to a specific Qt version (I consider that nothing shocking and a minor price to pay).
>>> Do I need to add some glue to the CMake file so that it will warn if the private headerfiles are not available? Apparently no changes were required to find them.

File Attachments

purely native OS X theme
native theme but with `-style kde`
using the KDEPlatformTheme
on Linux, using a purely "native" theme
KDEPlatformTheme with the "macintosh" native theme selected
kate built by Christoph Cullman as a completely standalone app bundle
kate/MacPorts in fully native Mac mode (but using XDG-compliant QSPs).
kate/MacPorts using the QtCurve style (but the native platform plugin)
kate/MacPorts using the KdeMacTheme plugin and the macintosh style
kate/MacPorts using the KdeMacTheme plugin and the QtCurve style


René J.V. Bertin

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

More information about the kde-mac mailing list