You have to register the expected Response first!

In my case it was like

#include <QtDBus/QDBusMetaType> // ... typedef QMap<QString, QMap<QString, QVariant> > ConnectionDetails; Q_DECLARE_METATYPE(ConnectionDetails)

and

int main() { qDBusRegisterMetaType<ConnectionDetails>(); // ... }

Hi,

Warning I am no expert of that module.

That said, I would rather go with QDBusVariant and make your std::variant available to Qt's QVariant class.

This question is a bit old now, but I ran into the same problem without finding a solution elsewhere, so maybe this will be useful for others to know.

I tried exactly the same code as you, and found the the same issue of the signal not connecting properly. What worked for me was to add the following somewhere in the code (e.g. the class constructor) to get executed before the connect() call.

#include <QDBusMetaType> // Add to code (e.g. constructor) to be run before the connect() call qDBusRegisterMetaType<InterfaceList>();

The connect() call then returned true, the signal fired, and I was able to extract the object properties straight from the InterfaceList object passed with the signal.

I don't believe the message protocol contains that information unless your sender manually inserts an ID into the message being sent. A web search indicates there are some out of band mechanisms to determin the PID of a program using a specific bus endpoint, but not directly within the dbus messages.

If I'm wrong then I'd love to see the solution myself.

I've solved it.

To handle long I did not have to send immediately reply (even though tutorial said that we have to). And delayed reply will be send.

Also in extension, QDBusPendingReply<QString, QByteArray> reply = *call; setting expecting signature to \"say\" and not looking to xml interface.

@SGaist You're right,I did not think about it! I have to remove the systemBus, I'm not using it in reality, it's part of the project that I found on Github. Ok then I can try to make it an instance variable of the class or similer. Thank you!

I have found solution for this, using QDbusConnectionInterface instead QDbusServiceWatcher:

connect(QDBusConnection::sessionBus().interface(), &QDBusConnectionInterface::serviceRegistered, this, [=](QString a) { qDebug() <<"service R: " << a; });

@micland

WOOW!!! Thank you sooo much micland!! It works!!!
I tried a code similar to yours but some data were missing. Just needed to do a very tiny modification on your code:

qDebug() << key << value.variant().toString();

or directly

qDebug() << value.variant().toString();

Except it, it is perfect! Thank you again.
@micland said:

I have no clue why the qdbusviewer of Qt 5.6 is unable to call the DBus method but the code snippet above is working fine.

I hope it is going to change as I intend to use it or the 5.7 version very soon.

Cheers again.

@Mark81
I'm certainly not a D-Bus guru, my experience with it is somewhat limited. That said, I think QDBusReply::value can be used, provided you have registered your types.

Kind regards.

I confirm that adding the pthread library did the trick. But the question "why" is still there :)

@SGaist Okay, thanks :)