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.
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
