dfaure created this revision. dfaure added reviewers: pino, broulik, mart, davidedmundson. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. dfaure requested review of this revision.
REVISION 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. REPOSITORY R295 KCMUtils BRANCH master REVISION DETAIL https://phabricator.kde.org/D28765 AFFECTED FILES src/kcmoduleinfo.cpp src/kcmoduleinfo.h src/kcmoduleloader.cpp src/kcmultidialog.cpp src/kpluginselector.cpp src/ksettings/dialog.cpp To: dfaure, pino, broulik, mart, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
