KSettings::Dialog: add support for KPluginInfos without a KService
Summary: KPluginInfo evolved into an abstraction over old-style plugins (KService i.e. desktop files) and new-style plugins with JSON (KPluginMetaData/KPluginLoader). When porting kontact to new-style plugins, I hit the issue that KSettings::Dialog has a code path that creates a 'fake' KCM module just to get a checkable item in the config dialog. That fake module was using the plugininfo's KService, which was null, into the KCModuleInfo. So I added support for metadata-based plugins to KCModuleInfo. But rather than using KPluginMetaData and then turning KCModuleInfo into yet another abstraction over old and new, I just used KPluginInfo in there. One can still create a KCModuleInfo from a KService, but internally it'll use a KPluginInfo. This makes KCModuleInfo::service() dangerous now though, it can be null [but only in apps that start passing new-style KPluginInfos, so not in systemsettings5 yet]. This commits ports kcmutils away from it as much as possible. Test Plan: kontact's configuration dialog works (with and without my not-yet-committed port to KPluginLoader). systemsettings5 still works. konqueror's configuration dialog still works. Reviewers: pino, broulik, mart, davidedmundson, ngraham, svuorela Reviewed By: svuorela Subscribers: svuorela, cblack, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D28765
parent
65c82cad