[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]