Touchpad KDED module: Convert to JSON metadata

Authored by marten on Jun 5 2018, 11:34 AM.



This is now the preferred way of providing plugin metadata. It's not just a cosmetic change because there is an actual problem with the original: the desktop file kded_touchpad.desktop sets X-KDE-DBus-ModuleName=touchpad which is presumably intended to register the KDED module under that name on DBus; all of the clients access it with the interface path "/modules/touchpad". However, this key appears to be being ignored, and the module is registered under the path "/modules/kded_touchpad" which can be confirmed with qdbusviewer. This incorrect path means that touchpad control via the Plasma applet does not work, and 'kcmshell5 kcmkded' does not show the touchpad module status correctly.

This change updates the KDED plugin to use JSON metadata.

Test Plan

Built plasma-desktop with this change. Observed correct registration of the module name on DBus, correct operation of the Plasma touchpad applet, and of "kcmshell5 kcmkded" and "kcmshell5 kcm_touchpad".

Diff Detail

R119 Plasma Desktop
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
marten created this revision.Jun 5 2018, 11:34 AM
Restricted Application added a project: Plasma. · View Herald TranscriptJun 5 2018, 11:34 AM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
marten requested review of this revision.Jun 5 2018, 11:34 AM
davidedmundson accepted this revision.Jun 16 2018, 8:42 PM
This revision is now accepted and ready to land.Jun 16 2018, 8:42 PM

Should the patch be backported to 5.13 since it's a fix for the daemon according to the description?

This revision was automatically updated to reflect the committed changes.
fvogt added a subscriber: fvogt.Jun 18 2018, 6:44 AM

This doesn't seem to be in Plasma/5.13.

kossebau added a subscriber: kossebau.EditedJun 19 2018, 3:08 PM

This patch seems to have broken things ("kcm does not load") by what people reported in irc for 5.13.1.

By a quick investigation the main reason is, that the old plugin binary with the name "kded_touchpad" is used both to provide the plugin for kcm as well as the plugin for the kded.
See how both plugins had been registered for the TouchpadPluginFactory in the removed file plugins.cpp, with two plugin metadata desktop files referencing the very plugin "kded_touchpad" to find their repective plugin (the second via the "kcm" id): kcm_touchpad.desktop and kded_touchpad.desktop

By turning the actual plugin into the new-style "embedded json in custom path" type plugin, the plugin metadata for the kcm plugin is now pointing into the void, as both the name is now wrong as well is the plugin no longer in the common plugin dir, but in a subdir (not sure if kcm plugins are searched also in subdirs). In any case, the kcm plugin is no longer registered now in a factory, so even if the plugin was found, there is no kcm to load.

No idea where the actual bug this patch was supposed to fix is coming from, but it has broken things in a different way :)

One solution might be to properly split the current single plugin binary into 2 separate plugin binaries, one per kcm and one per kded plugin, and add a shared private lib for the stuff they might share.

Given the D-Bus object path for the module is generated from the moduleid, which is set by kded using the KPluginMetaData::pluginId (in KDEDModule *Kded::loadModule(const KPluginMetaData &module, bool onDemand), a fix might have been instead to set in the kded_touchpad.desktop file this entry: X-KDE-PluginInfo-Name=touchpad

Apologies for the unforeseen trouble. I'll revert the committed change for now, and then investigate the fix that @kossebau suggests in the previous comment. If this doesn't work then I'll look into splitting the kded and kcm modules into separate ones with a common library.

cfeck added a subscriber: cfeck.Jun 19 2018, 6:34 PM

Regression has been reported as bug 395622. Please close when fixed.

Apologies for the unforeseen trouble.

Happens also to the best now and then, and only to get better the next time :)

I'll revert the committed change for now, and then investigate the fix that @kossebau suggests in the previous comment.

Given the commits seems that worked out? Good, so I did not misread the kded code.

In the meantime I had tried to investigate where the X-KDE-DBus-ModuleName had been introduced in kdelibs/kde frameworks history and where/why it faded again, but so far have not found it being used at kded core at any time, only found traces in outer code spheres.

So am going to create some patches to wipe out the last traces of that key from other KDE code, everything I saw should work good enough using the plugin id, either derived from binary name or set by metadata (X-KDE-PluginInfo-Name with desktop file and KPlugin/Id with JSON). So in the future no-one can be confused by that non-working key anymore.

dfaure added a subscriber: dfaure.Oct 26 2019, 8:26 PM

I didn't fully follow this saga, but AFAICS this patch was reverted (commit 3432c3342b1f801, bug 395622), so we still rely on desktop files to load the touchpad kded module. Can this patch be applied again now that commit f040cdb399b (X-KDE-PluginInfo-Name=touchpad) is in, or is something else missing?