**** BEGIN LOGGING AT Fri Feb 19 02:59:57 2010 Feb 19 18:01:40 akiniemi: Did you get a chance to test the latest USSD changes for dialogs? Feb 19 20:16:40 holtmann, denkenz, padovan, there is a bug on on hfp plugin, currently if you don't set have both connect and disconnect callbacks gdbus removes the filter after the callbacks returns, so in hfp case it means it will only call bluetooth_disconnect and we will need to keep adding the watch again or have a connect callback, but this sounds not very convenient to me so what about having a gboolean as return as we have done g_dbus_add_signal_watch which is simila Feb 19 20:16:40 r to what g_io_add_watch or keep the current behavior only when the sender is a bus names not dropping when it is a service name which may be owned again. Feb 19 20:22:19 The second option may sound more appealing as there is no need to change the API, but the first one gives more control to the code using to remove the watch without having to store the handle and call g_dbus_remove_watch. Feb 19 20:32:08 Vudentz: sorry which watch are you referring to? Feb 19 20:32:39 Vudentz: The bluetooth_exit_watch? Feb 19 21:02:11 denkenz: I did, and they looked okay to me. Feb 19 21:06:33 denkenz: ah, you actually asked whether I had tested them, no. Not yet. But the patches looked ok. :) Feb 19 21:09:37 akiniemi: Heh Feb 19 21:35:51 denkenz, yep Feb 19 21:38:06 Vudentz: So the question is why is the watch being removed automagically? Feb 19 21:38:38 Vudentz: Which I find less than intuitive :) Feb 19 21:40:05 Vudentz: And I'm personally fine with either adding connect callback or using a returning gboolean, but the latter might affect too many applications Feb 19 23:06:02 denkenz, historically we use this watches only to track bus name (x:yz) of the applications which once disconnects/connects you will probably never see them again, but service names can change. Id probably fix it by checking if the watch is for a service name and then keep it, this actually would solve may original problem which was to properly support service name in g)dbus Feb 19 23:06:34 g_dbus_add_signal_watch Feb 19 23:12:16 sounds good to me **** ENDING LOGGING AT Sat Feb 20 02:59:57 2010