https://bugs.kde.org/show_bug.cgi?id=478091
--- Comment #4 from Jakob Petsovits <jpe...@petsovits.com> ---
KCModuleLoader::loadModule() has the correct metadata available when it returns
it to System Settings' ModuleView, but the instantiated KCModule object does
not carry that same metadata.
KdeConnectKcm (which powers kcm_kdeconnect.so) is using the older constructor
signature (QObject *parent, const QVariantList &args) and from what I can tell,
KPluginFactory is forgiving enough to call that instead of requiring the plugin
to support the newer version that also contains the metadata.
The KdeConnectKcm constructor then initializes its parent as simply
KCModule(qobject_cast<QWidget *>(parent)). As a subclass of KCModule, it's
allowed to do this, however KCModule also warns:
/**
* Utility constructor for creating a KCModule that is embedded, for
example in a KPluginWidget
* This constructor should not be used for KCMs that are part launched in
systemsettings!
* (...)
*/
explicit KCModule(QObject *parent)
: KCModule(qobject_cast<QWidget *>(parent), KPluginMetaData{})
{
}
So it seems the solution is for KdeConnectKcm to use the more modern
constructor signature and hand down the KPluginMetaData object to KCModule, as
it's supposed to do. I'm sure it's the same issue with the Digital Camera KCM.
I don't quite understand the KPluginWidget use case that apparently allows
plugins to use the wrong constructor, but presumably it's required for
something. It would have been nice if the KCM developers had been loudly warned
about using the wrong constructor.
--
You are receiving this mail because:
You are watching all bug changes.
