KCoreAddons qml plugins

[Stephen Kelly]

Aleix Pol wrote:
>> 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] 

> 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.

Sorry, I'm a bit confused.

Are you suggesting libKF5CoreAddons.so should link to QtQml, or are you 
suggesting creating a new KF5::CoreAddonsQmlPlugin in the kcoreaddons repo?

The latter sounds more appropriate to me.

> 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 because it takes some effort to make a class ready to be used in a 
declarative environment like QML. 

Thanks,

Steve.