[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
style).
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
apply.
R.
More information about the Development
mailing list