On Thu, Jan 28, 2016 at 8:12 PM, Stephen Kelly <steve...@gmail.com> wrote:
> 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.Yes, I was referring to having the plugin there, not a library. In fact, the only reason to depend on QtQml is the plugin itself, rather than the bindings, which usually don't have QtQml stuff (although they might). Aleix _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
