KCoreAddons qml plugins

[Aleix Pol]

On Thu, Jan 28, 2016 at 1:11 AM, David Faure <faure at kde.org> wrote:
> On Wednesday 27 January 2016 18:19:49 Aleix Pol wrote:
>> Hi,
>> I would like to move KCoreAddons qml plugin into KCoreAddons. Now it's
>> KDeclarative where we are dumping all QML plugins.
>>
>> I think it's a good idea because:
>> - it simplifies usage  the plugins for such frameworks (kcoreaddons is
>> not the only one).
>> - it ensures the code related to a feature is together.
>> - it keeps the documentation together.
>> - we don't force unwanted dependencies [1].
>>
>> The only downside I see, is that KCoreAddons will end up depending on
>> QtQml. I think we can make it an optional if that's a problem on some
>> setups.
>
> That's a major downside. KCoreAddons is supposed to be only depend on QtCore.
>
> This is like saying the QML bindings for QtCore classes should be in QtCore
> (apart from the obvious technical impossibility).
>
> One of your reasons in favour is "we don't force unwanted dependencies",
> and your solution is to add a (very unexpected) dependency from KCoreAddons to QtQml...
>
> "Making it optional" is only a half-solution. With distro packages or other kinds
> of pre-compiled binaries, one ends up with a forced dependency. Using
> the plugin infrastructure from kcoreaddons, or the Job classes, to write a core-only
> application (or a widget application) should not require QtQml, since such an
> app would having nothing to do with Qml.
>
> QML bindings are "one layer above" the class they bind. Just like kdebindings is separate
> rather than "mixed into every framework". Having the javascript bindings for KIO in KIO
> would tick all your criterias above ("simpler to use because part of the framework",
> "all the kio related code together", "doc together", "no kdebindings-depends-on-everything").
> And yet we don't do it. Because KIO users don't want to be forced to install python.
> Similarly, many users of kcoreaddons don't want a dependency on QML.
>
> I honestly don't see the problem with having this in KDeclarative, but maybe I'm missing
> a good reason for splitting such qml plugins into a separate framework. Or maybe
> there's no point in doing that either.

Personally, I don't really see how QtQml build-time dependency is
holding back the adoption of KCoreAddons. Is QtQml something that
often isn't available?

Distributions might add the dependency, but they also end up splitting
the packages [1] if they consider appropriate, so this wouldn't have
an impact on the Linux-distro end-user.

As I see it, we shouldn't consider them bindings, but part of the API.
The fact that (some of them) are implemented using façade classes is
mostly a symptom that we need to learn to expose better to QML and
that Qt needs to improve (for example, in this regard I see Q_GADGET
in the right path). Furthermore, I don't really see kdebindings as a
good example, since it's always felt like a second-class citizen,
lacking in documentation and maintained by second or third parties.

>From a KDE Frameworks point of view, QML is not Python. QML is part of
Qt (albeit not qtbase, I'll give you that) which is the direct
upstream of KDE Frameworks and as much as QtScript can be for KI18n
[2]. This is specially important I think, because it leverages that
the platform we're building on is already Qt-proof (but might not be
Python-proof, for that matter) [3].

I think the KIO example is a good. I think we should be open to making
it possible to use KIO on QML. I would say that if this hasn't
happened, it's because it's some API that is rather complex and Qt
might choke on it, but it's not my impression that the reason that KIO
has KF5::KIOWidgets and not a qml plugin is because we decided we
wanted one and not the other, but mere historic reasons.

The problem I see with having a big KDeclarative framework is that it
requires to have many KDE Frameworks available. The root
CMakeLists.txt file [4] already shows that it's full of conditionals
and it largely depends on whether the actual framework is available.

Aleix

[1] http://packages.ubuntu.com/search?keywords=qml
[2] http://api.kde.org/frameworks-api/frameworks5-apidocs/ki18n/html/ki18n-dependencies.html
[3] https://paste.kde.org/pb2jgs4aq
[4] https://quickgit.kde.org/?p=kdeclarative.git&a=blob&h=9c1a11c735aa5e5a2a3e99a5c15ce1e99a4e7515&f=CMakeLists.txt&o=plain