KCoreAddons qml plugins

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5