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.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
