Michele Calgaro wrote: > Hi Emanoil, > where are you with this? and can you share a link to the original code? > cheers > Michele 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
/usr/bin/g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time \ -D_FORTIFY_SOURCE=2 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT \ -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/usr/include/tqt3 \ -I/opt/trinity/include/ -I/usr/include/dbus-1-tqt -I/usr/include/tqt -DQT_NO_ASCII_CAST \ -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT \ -D_REENTRANT -include tqt.h -g -Wl,-z,relro tqdbusbt.cpp -o tqdbusbt -ldbus-1-tqt -ldbus-1-tqt \ /opt/trinity/lib/libtdeparts.so.2.1.0 /opt/trinity/lib/libtdeio.so.14.0.0 \ /opt/trinity/lib/libtdecore.so.14.0.0 -ltqt -ltqt-mt -lXrender -lX11 -lc \ /usr/lib/x86_64-linux-gnu/libz.so -lidn -lXcomposite -lICE -lSM -lutil -lr -lacl -lattr -ltqui
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: trinity-devel-help@xxxxxxxxxxxxxxxxxxxxxxxxxx Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting