Scope of framework integration plugin?

[René J. V. Bertin]

Adding KDE-mac because we're the first concerned (thanks for omitting us ... 
again).

First off: what about splitting off the KdePlatformPlugin from 
frameworkintegration? I can see the point that it was conceived to allow pure 
Qt5 applications to integrate with the look KF5 applications have under Plasma.
Make the plugin a standalone component (and dependency for fwintegration), and 
the whole theoretical argument around platform integration becomes moot.

Luigi Toscano wrote:

>> Now I understand that some people don't like the native look of their
>> platform and would prefer using Plasma. 

It is not really about using Plasma. It's also not about forcing anyone to use 
something other than a native look. It's above all about being able to have a 
good and professional look, if possible one that can be tuned to personal 
preference or requirements.
And it's above all too about not forcing anyone what NOT to do based on the same 
kind of dogma that Apple is usually accused of rather than praised for.

I have always believed that one can be most productive if one can adapt one's 
tools rather than having to adapt to one's tools. That may mean that some "angry 
teenager" can completely f**k up his/her environment with counterproductive 
choices, but so what?

>> Sorry I don't have an answer to that

You don't need to, I already found *an* answer. Or a beginning of an answer if 
you prefer.

>> Unfortunately I think it's completely out of scope for the
>> integration platform to be considered outside Plasma.

>From what I can see there is very little in frameworkintegration that is purely 
about Plasma.

> Really? I see people trying to use KDE Applications (for example on #kde) on
> different desktop environment and being confused for the look and feel. I
> understand that:

> - you don't want the Plasma look used outside Plasma

Can someone define what the "Plasma look" is? Breeze? Fine, Plasma can keep that 
one -- but just as I don't want to be told what I'm allowed to use based on some 
dogma that really has no place in a collaborative, open software community I do 
not want to be the one to tell others from KDE-Mac what they're allowed to do or 
not.
Either way, "Plasma look" is what the user defines it to be. Configurability has 
always been central to KDE, and I don't think that should stop.
Heck, it's one of KDE's main arguments and reasons I've started to use KDE 
applications over their Apple-provided counterparts.

> - yes, other desktop environment should provide and integration plugin

I agree, but only to the extent that the current integration plugin doesn't "cut 
it". There's no reason to waste efforts to rewrite something that already does 
the trick.

That said, I will repeat here what I said in another thread:
There are various reasons why I think the look-n-feel of KF5 (but really, Qt5 
apps in general) is insufficient on OS X. Qt provides a common denominator that 
provides a workable compromise on all platforms, but doesn't go beyond that. 
Understandably, in a way. Case in point: Qt Creator doesn't use the default, but 
elaborates on it to provide a much better experience (that still suffers from a 
misconceptions in the domain of the font sizes used throughout the interface).
I've tried to take this up several times on Qt MLs and even in bug report(s), 
but there is clearly little to no animo to act on this. Again, that's probably 
understandable: fine-tuning something like fonts to use is highly application-
specific. Colour palette is affected in a similar fashion, btw.
The code that implements the native OS X style is also pretty complex with its 
mix of C++ and ObjC, so not very accessible to outsiders.

The best way I see to improve the native look-n-feel on OS X (and possibly other 
platforms) is to implement a dedicated theme. KDE applications are already wired 
to use different font and icon roles. The font roles are KDE specific and can 
thus only be handled in KF5 code for now, or else all applications would have to 
be riddled with ifdefs. But it should be feasible to write a theme that 
overrides only the native methods that require it in order to apply the 
requested font sizes/styles, icons and why not even colours.

As I said in another thread, it might even be work to request the native theme 
through KF5's theme selection mechanism, and apply font, icon etc. settings 
through the existing KdePlatformPlugin with my modifications.

And if that's true (or with an improved "native" theme), frameworkintegration 
would be squat in its designated role, be it on a platform that's not Plasma.


> but isn't it really possible to have a "simpler" default integration plugin,
> when no one else is provided, that at least show the icons, for example?

If you mean the user's selected icon theme, then yes. I'd give priority to 
his/her fonts of choice, but the choice of icons is definitely part of what 
should be respected if the user indicates s/he wants this.

> That would belong into Qt, shouldn't it?
> Qt already provides QPlatformTheme plugins that integrate on those
> platforms. If they don't work, we should fix them upstream.
> 

And why would that be any different on Plasma? The qgenericunixtheme already 
contains (outdated) logic that reads KDE settings.
True, I might have used the same techniques I used in my fwintegration patches 
to patch the qgenericunixtheme, and achieve similar results. But the same can be 
said the KdePlatformIntegrationPlugin.

But I'm sure anyone who's ever tried to get Qt patches incorporated knows how 
(understandably) difficult that is (and so tedious that there's at least 1 
company that made it its business). Would you really expect Qt to accept a patch 
that allows generic applications to use font role specifications from KF5? 
They'd rightfully reject such a patch because it'd be up to KF5 to provide the 
glue required to make that work.

> I'm assuming we agree that we expect applications on non-plasma
> platforms to look and behave native.

No. Not if it means that that other choices are off-limits. And not if it means 
you end up stuck with a common-denominator compromise.

> I think we are not helping users of KDE applications but not Plasma users, and
> let's be realistic about the possibility of other desktop environment
> providing an integration plugin.

To repeat something else: simply using QT_STYLE_OVERRIDE or `-style XX` is a 
step in the right direction. But where it was actually enough with Qt4 (in that 
it changed widget drawing and fonts used), it is not with Qt5 (where it only 
changes widget look and layout).

If there were a way in Qt5 to load and apply other settings (esp. fonts) then I 
would not have made the RR that led to this thread. Sadly there is none.

>> Given that: if people agree with my view that the framework integration is
>> only about Plasma, I suggest that we move the framework integration to kde/
>> workspace to release it together with Plasma instead of frameworks.
> 
> IMHO only if it's possible to package and load it outside Plasma, or otherwise
> if there is a more sane default plugin.
> 
> Ciao