[Development] extending the cocoa native style via a plugin: feasible?

René J. V. Bertin rjvbertin at gmail.com
Tue Dec 1 13:00:44 CET 2015

Olivier Goffart wrote:

> I don't understand why you need such plugins.

I had hoped to make that clear...
I had also hoped to avoid this turn in the discussion, at least not at once ...

> Why would KF5 applications be any different than normal Qt5-only applications?

Because they are? KF5 provides facilitates that allow applications to elaborate 
on Qt features -- that's a bit the whole idea of the KDE 5 frameworks, right?

I think it's perfectly understandable that Qt itself provides a more or less 
minimum, common denominator set of widgets and UI design features that provide a 
reasonable, working experience across all platforms. That doesn't mean you get 
an optimal UI out of the box, on all platforms. I'm pretty sure that if you look 
at applications that do provide a more streamlined, non-standard look (like 
VirtualBox or Parallel Desktop, or even Qt Creator) you'll find that they either 
use platform-specific code, or they implement their own style plugin. Which 
wouldn't be much different from KDE's platform plugin, except for a single style 
and only a single, standalone application.

> The idea is that a KDE applications running on OS X would try to integrate as
> much as possible within the native style.

Yes, but except for a few very strict environments, OS X does not impose the use 
of only a single font family, style and size, to name just one aspect of the 
native style. On the contrary, if you look at the native toolbox, you find a 
comparable set of predefined font roles and corresponding settings (plus the 
possibility to do something different), and native applications do indeed make 
use of them. At the very least that leads to applications that provide much more 
compact interfaces that waste much less space (and quite frankly, look more 
professional, less like they were thrown together by someone who doesn't know 
what s/he was doing ... or couldn't care).

I also do think it is perfectly justifiable to allow application suites to 
provide a coherent experience, and even one that is as coherent as possible 
across platforms if the developers or even (advanced?) users decide that works 
best for them. Current trends seem to go that way (look at Google Chrome...) but 
I am *not* saying this should be the default behaviour, nor that Qt should 
provide everything required for that. The key concept here is "allowing".

> If an application whishes to do differently, it can still override the default
> palette or font at the application level, and there is no need for a plugin to
> do that.  (and one of the KF5 libraries could do that.)

To put that in perspective: we're not talking about individual applications 
here, but about a whole *cross-platform* family of applications that are already 
"prewired" to select specific fonts, icons, palettes etc.

Yes, a KF5 library could provide the theme in question, and basically the 
"frameworkintegration" framework already does. Except that it's platform theme 
plugin ("KDEPlatformTheme") doesn't load on OS X without patching Qt. As I said, 
just using QT_STYLE_OVERRIDE or the -style option does only part of the work, 
and in a sense the wrong part, the one that applies the (non-native) look from 
the active KDE "widgetStyle". So Qt would still have to allow that 
"KDEPlatformTheme" to be loaded, like it does on other Unix variants, under 
certain conditions that I think are highly unlikely to occur by chance (= for 
the average unsavvy "Joe User").

Disambiguation: there a source of confusion between the active KDE theme 
("widgetStyle"), and the KDEPlatformTheme plugin. The latter is the theme that, 
when available, is loaded by Qt (in init_platform(), through the theme factory), 
under a Plasma session on Linux (and on OS X with a small modification). It does 
not itself provide any theming, but provides the glue required for the 
"widgetStyle" full feature set. It loads those settings, for instance that are 
not specific to the selected widgetStyle.
I have not found a way to request the KDEPlatformTheme plugin via a commandline 
or env.var. control; QT_STYLE_OVERRIDE and "-style" both load only a widgetStyle 
("-style kde" loads the active widgetStyle, "-style QtCurve" loads a specific 

Mind you though, there are a few vocal/opinionated KDE developers who feel that 
KDE should not allow anything that's "not native". And that if KDE users on OS X 
are unhappy with the way that makes things look, they just have to improve Qt 
I don't condone that view (esp. not from people who don't use OS X themselves), 
but also don't think it's possible to put the whole burden in the KDE camp. 

> Or are you trying to run Plasma on OS X?

No, I'm not trying to run a full Plasma session on OS X. I realise this 
confusion can arise because what I am currently using is based on something 
that's supposed to integrate Qt with a Plasma environment.

The term "integration" is an appropriate one though, except I take it in a much 
broader sense.

Note that OS X actually does have a hidden feature (exposed by utilities like 
TinkerTool) to define different fonts (or sizes/styles/weights) for specific 
roles. Not as many as KDE provides, but those that do exist at least should be 
accessible via one of the SDKs, and if so should probably be applied by the 
current native theme in situations where the corresponding roles are known to 


More information about the Development mailing list