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