QDbus: connection fails but lastError indicates no error
-
I tried using the extended variant of the
connect()
method:auto ret = QDBusConnection::systemBus().connect( "org.veki.CloudAgent1", "/org/veki/CloudAgent1", "org.freedesktop.DBus.ObjectManager", "InterfacesAdded", "a{sa{sv}}", &receiver, SLOT(InterfacesAdded(QDBusObjectPath, QMap<QString, QVariantMap>)));
Same (lack of) effect.
-
This
delivery is suspended
message and the subsequentdequeueing the message
one are part of the normal flow it seems. It dequeues the message once the main loop is running. Still not sure why I can't connect to the signal. I checked withgdbus monitor
and a bit of python code usingpydbus
and the provider of this signal works just fine, I can connect to it and be notified when it's triggered. -
Are you using the Qt version of your distribution ?
-
I tried this on qt5 & qt6 from the distro (ubuntu 22.04). I tried the same on a yocto based OS with meta-qt5 and meta-qt6 respectively. Qt6 version is 6.4.1. I tried switching to session bus (but that shouldn't matter as
gdbus monitor
works fine as does pydbus, no issues with dbus config).I created a very minimal example with a pydbus provider that after 5 seconds adds an interface:
#!/usr/bin/env python3 import pydbus import pydbus_manager from gi.repository import GLib from functools import partial class Provider: """ <node> <interface name='org.dupa.Provider1'> <property name='Dupa' type='s' access='read'/> </interface> </node> """ @property def Dupa(self): return "dupa dupa" def add_interface(manager): print("Adding object") manager.register_object("/org/dupa/Provider1/Dupa", Provider(), None); return GLib.SOURCE_REMOVE if __name__ == "__main__": loop = GLib.MainLoop() bus = pydbus.SessionBus() manager = pydbus_manager.Manager(bus, "org.dupa.Provider1") GLib.timeout_add_seconds(5, partial(add_interface, manager)) loop.run()
And the minimal Qt example doesn't work with it all the same. It seems to me that if
connect()
returns false but no error is set, then it's a bug in the library?It's probably something stupid but I cannot figure it out.
-
To make things simple to test:
- Can you provide a requirement.txt for your example script ?
- Can you provide a minimal C++ example that uses your provider for testing as well ?
That way it will be easier to reproduce your issue in similar conditions.
-
Hi @SGaist !
Here's a repo with a functional example: https://github.com/brgl/qdbus-signal-example
Inside you'll find a
requirements.txt
file for the python scripts, a functional python signal provider and receiver and a qt6 receiver that doesn't work.For simplicity it uses the session bus. You need to run
python-provider/provider.py
and then within 5 seconds run thepython-receiver/receiver.py
script and observe that it correctly receives the signal. You can then runqmake6
andmake
inside theqt6-receiver
directory and do the same for the qt receiver program. It will fail to connect and not receive the signal as well as not indicate any error.Let me know if that's clear and thanks for helping!
-
I am suspecting that there's an issue with the signature of the slot but I haven't been able to pinpoint it.
The D-Bus type is
a{sa{sv}}
So it's a dictionary with string as key and as value a dictionary with string as key and variant as values. The variant is mapped to QDBusVariant based on D-Bus type system so I would check in that direction. -
https://doc.qt.io/qt-6/qdbustypesystem.html#the-type-system-in-use Does this:
Warning: You may not use any type that is not on the list above, including typedefs to the types listed. This also includes QList<QVariant> and QMap<QString,QVariant>.
Mean I cannot receive signals passing dicts as arguments?
QDbusViewer is telling me:
Error: Unable to connect to service org.foobar.Provider1, path /org/foobar/Provider1, interface org.freedesktop.DBus.ObjectManager, signal InterfacesAdded
-
I've been browsing the KDE Udisks code that uses qt AND connects to the InterfacesAdded signal. I added some bits that were missing from my code:
typedef QMap<QString, QVariantMap> QVariantMapMap; Q_DECLARE_METATYPE(QVariantMapMap)
and
qDBusRegisterMetaType<QVariantMapMap>();
but that didn't fix it.
-
Can you point me to code in question ?
Did you try with QDBusVariant in place of QVariant ?
-
The code's here: https://src.fedoraproject.org/rpms/kdelibs/blob/f94c05b3732a163d5bf76a9dc52d51688339b812/f/kdelibs-udisks2-backend.patch
And yes, I did try to use QDBusVariant with no effect.
-
After some more trial and error I finally figured it out.
Basically I need to use
QDBusVariant
AND also register both the single map and the "mapmap" type:typedef QMap<QString, QDBusVariant> QDBusVariantMap; Q_DECLARE_METATYPE(QDBusVariantMap); typedef QMap<QString, QDBusVariantMap> QDBusVariantMapMap; Q_DECLARE_METATYPE(QDBusVariantMapMap);
and
qDBusRegisterMetaType<QDBusVariantMap>(); qDBusRegisterMetaType<QDBusVariantMapMap>();
and
auto ret = bus.connect( "org.foobar.Provider1", "/org/foobar/Provider1", "org.freedesktop.DBus.ObjectManager", "InterfacesAdded", &receiver, SLOT(InterfacesAdded(QDBusObjectPath, QDBusVariantMapMap)) );
Honestly the error reporting on this thing could use some more work. :)
-
Nice !
I agree with your suggestion. Did you already check the bug report system about that matter ? If there's nothing there, you could open a feature request to improve that message.