Scope of framework integration plugin?

[René J.V. Bertin]

On Monday November 30 2015 16:07:50 Jan Kundrát wrote:

Hi,

>Yes, I think that such a goal is fully in line with Qt's attempt at being 
>reasonably cross-platform.

The keyword here is reasonable - and that's to be interpreted from their point of view. The last time we (including David Faure) attempted to introduce a patch to Qt that was largely motivated by its importance for KDE (and other non-Qt5-based XDG-compliant software though we didn't stress that enough) the reaction boiled down to "KDE business should be settled by KDE, we don't care about cross-platform KF5 applications".
When I filed a bug report about the texted separators used by QMenu menu sections (with a suggested workaround that prevents losing the information in the text) it was rejected, referring to the documentation that states that "this only works on platforms that support the feature", and stating that cross-platform applications simply shouldn't use menu sections.

Qt also has developed a rather hostile attitude towards the whole idea of theming (and the remarks I've seeing a not-so-distant past did not make exceptions for Plasma) and then there is the whole aspect of app store admission conditions. That aspect is one of the main reasons why the QtConfig tool was discontinued and won't be coming back (despite popular request, not just from me). Not that a theme plugin with user-configurable settings cannot be made to comply with sandboxing principles, but something like an Apple App Store *is* a place where rules against anything that even allows the user to "look different" (pun intended) can be applied. That too can be worked around by making it possible not to include the component(s) that make this possible (cf. the frameworkintegration framework), but you end up with a situation complex enough to elicit a very quick "forget about it".

>In my experience, the Qt developers usually respond very well to patches in 
>Gerrit.

Can you imagine how they'll react to a patch that either introduces a (circular) dependency on KF5, or that requires duplicating code from KDE?

I think we're more in a situation like the one that existed when Qt5 was being drafted, and swaths of code were transferred from KDE4, and other classes (QStandardPaths) designed inspired by stuff from KDE4 and their proven added value.

>Cheers,
  ^^^^^
that was before I filed my RR :P

R.