In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

It is redundant since the parent class, KConfig, has locationType().

Add some API docs for fileName(), even though one could use KConfig::name()
from the parent class, I think this would be confusing given a .desktop file
has a Name= entry, so fileName() is less ambiguous.

These seem to be leftovers from a previous refactor that happened a long time
ago.

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.

NO_CHANGELOG