|
This way consumers which want to use the ConfigPropertyMap don't have to
pull in KDeclarative's entire dependency tree.
Also we can remove the automatic saving of the config, previously
this was opt-out - which makes is difficult to deprecate anything.
This way the API design is also more clear, since the object only takes care of exposing the
data to QML. The writing has to be done manually, which makes more sense anyways when we have
the notify opt-in.
As discussed on the KF6 weekly thread, an optional QML submodule is seen as the best
way to handle the QML dependency.
Task: https://phabricator.kde.org/T12131
Relates to https://phabricator.kde.org/T12126, after his change the KDeclarative stuff can be deprecated.
Because we don't register the property map in any QML plugin, there is
no conflict in duplicating and modifying it now.
|
