Michele Calgaro wrote: Hi Michele, $ dpkg -S /usr/bin/dbusxml2qt3 libdbus-1-tqt-dev: /usr/bin/dbusxml2qt3 To my original message - I see a problem with TQMap - TQMap< TQT_DBusObjectPath, TQT_DBusDataMap< TQString > generated by the tool is not supported. I worked around it by changing the generated code to use TQT_DBusData, but it is not the end of the story. So let me explain Now I was looking in an option to reuse the gui for kbluetooth and rewrite the code to work with bluez5. I have been missing this since 2008, when I saw it in SuSe. In the meantime bluez changed a lot - perhaps for the better, so the code base is not really usable. In official bluez5 docs it says the entry point is ObjectManager in root of org.bluez. I try to retrieve and parse the data (objects) returned from ObjectManager when calling GetManagedObjects but I hit one problem and I think it boils down to dbus-1-tqt and perhaps TQMap as mentioned above. I have 3 devices paired. The problem is that using tqt I get only the last object path back. However, when using dbus or qdbus I see all of them including the moregeneral paths. For example if I call qdbus --literal --system org.bluez / org.freedesktop.DBus.ObjectManager.GetManagedObjects or dbus-send --system --print-reply=literal --dest=org.bluez / org.freedesktop.DBus.ObjectManager.GetManagedObjects I have /org/bluez /org/bluez/hci0 /org/bluez/hci0/dev_xx_xx_xx_xx_xx_01 /org/bluez/hci0/dev_xx_xx_xx_xx_xx_02 /org/bluez/hci0/dev_xx_xx_xx_xx_xx_03 With the code attached I am seeing only the last one /org/bluez/hci0/dev_xx_xx_xx_xx_xx_03. If there is no adapter attached, I see /org/bluez When removing dev_xx_xx_xx_xx_xx_03 I see only dev_xx_xx_xx_xx_xx_02. After pairing dev_xx_xx_xx_xx_xx_03, I see again only this path. I need help to overcome this obstacle, please. It might be also that I am doing something wrong as well :), but could be that there is something wrong handling such scenario So these are the two problems I face: 1. I get only last object path from ObjectManager 2. TQMap does not support TQMap< K, TQT_DBusDataMap< T > > I tried parsing the result from ObjectManager with both TQMap and TQT_DBusDataMap with same result. I have not looked into the dbus-1-tqt code (yet), but it could be toObjectPathKeyMap or map handling is somehow broken. So I am going to write a test next to construct and deconstruct objectpath maps in similar way they are returned by ObjectManager and I will report back. If you or someone else could help with #2, it would be also great. I looked into the code briefly and from what I have seen there is no valid template to handle this case. regards

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2018/05/30 04:09 AM, deloptes wrote: I will try to take a look at this during the weekend and give some feedback. Cheers Michele

Hi Please, have a look at this - why it fails here TQValueList<TQT_DBusData> list = data.toTQValueList(&ok); is it only on my system or you see the same? is it me making a mistake or it is a bug? when I remove the condition it works though I wouldn't expected if it fails to has any data in the list. TQValueList<TQT_DBusData> list = data.toTQValueList(&ok); if (!ok) kdDebug() << "toTQValueList failed" << endl; else kdDebug() << "toTQValueList worked" << endl; // if (!ok) return -1;ok = false; thanks in advance regards