[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Scope of framework integration plugin?
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2015-11-30 15:32:22
Message-ID: 5754114.83zdLecPqp () patux
[Download RAW message or body]

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.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]