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