Skip to content

kio-mtp: register demon on D-Bus by service name org.kde.kmtpd5

Friedrich W. H. Kossebau requested to merge work/kossebau/fixmtpdbusservicename into master

Currently nothing tries to address the service via the well-known name, but in case someone starts to do so, fixing X-KDE-DBus-ServiceName in the JSON metadata to match the name used in the D-Bus service file should ensure things work as expected. Using org.kde.kmtpd5 as well-known service name matches the pattern seen elsewhere with KDE services.

@dfaure

Three questions:

A) I was triggered to look at this given the current "X-KDE-DBus-ServiceName": "kmtpd" in the JSON metadata, which for one does not match the name in the installed service filename, but also is not correct by D-Bus specs IIRC, at least kiod fails to register for that name.

But given the currently the kio-mtp code only explicitly connects to the kiod service and the very module object:

    m_dbusInterface = new org::kde::kmtp::Daemon(QStringLiteral("org.kde.kiod5"),
            QStringLiteral("/modules/kmtpd"),
            QDBusConnection::sessionBus());

I wonder if the current logic of kiod which emits a warning if there is no service name for a kiod module is requiring too much? Do we expect all kiod modules to provide an own full service?

B) Also why is there a kiod != kded now, that is not really documented when to use which? kio-extras has some more kded modules, should they rather become kiod ones now?

C) kiod seems to support kdedmodule-like plugins, also by the traces of "ServiceTypes": [ "KDEDModule" ] on some JSON metadata. But entries like "X-KDE-Kded-autoload" & "X-KDE-Kded-load-on-demand" seem to be ignored. Where is this documented? Is there some spec at all for the data scheme of the JSON?

Merge request reports