kconfig: support passing in a QIODevice

sometimes we don't actually need or have a backing file on disk but still want to parse config data. previously this required dancing with a temporary file to load/write stuff.

to more conveniently support such use cases KConfig gains a single new constructor that accepts a QIODevice instead of a file name.

unfortunately the KConfig internals are a bit poorly separated so it's a bit unclear when files are used and when not, leading to some unused code paths depending on the scenario (notably the fileName is empty for QIODevice based configs). fortunately the inibackend has more reasonable separation already so I doubled down on that and split out a KConfigIniBackendAbstractDevice which gets implemented by a PathDevice and a QIODevice class encapsulating the open/create/write logic for a given backend type and providing the backend with a QIODevice it can work with

API Added (so far):

KConfig::KConfig(const std::shared_ptr<QIODevice> &device,
                     OpenFlags mode = SimpleConfig);

KConfigSkeleton::KConfigSkeleton(std::unique_ptr<KConfig> config, QObject *parent = nullptr);

KCoreConfigSkeleton(std::unique_ptr<KConfig> config, QObject *parent = nullptr);

There is a small price to pay: KCoreConfigSkeleton will have both a std::unique_ptr<KConfig> additionally to its KSharedConfigPtr. Each stay null as the other is used.

Dolphin MR: system/dolphin!1118

Edited by Méven Car

Merge request reports

Loading