On Thu, 2012-08-23 at 16:39 -0600, Jeremy Whiting wrote: > Patrick, > > Thanks for your guidance today. I got my branch uploaded to > http://cgit.collabora.com/git/user/jwhiting/syncevolution.git/ it's > the syncpbap branch.
Wanted to look at it today, but haven't gotten around to it - sorry. > Currently it starts the transfer and does work > (I see vcard data in the file) however as you can probably see my > SignalWatch understanding is not that great. I thought I could watch > the transfer path, but apparently SignalWatch only works on a remote > dbus object, not an object and path. SignalWatch takes a DBusRemoteObject, which contains path, interface and sender (in this case incorrectly called "destination"). > I didn't quite follow what you > were saying earlier about putting a watch on everything, how would > that work (the signal is on the transfer path only, not the whole obex > client object)? The signal uses a path prefix which is the same as that of the session. Therefore, if there was a way to select a D-Bus prefix match, that session path could be used to restrict signal processing to signals of the current session. But neither GIO D-Bus (at least out of the box) nor the C++ binding for it support a prefix match. I suggest that you leave your code as it is for now. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
