GNOME Bugzilla – Bug 604628
creating an account causes weird behavior
Last modified: 2011-08-29 10:12:28 UTC
when I try to add a new account it does not look like it connects (no blinking protocol icon, no error infobar when the password is wrong). I can toggle enable/disable as much as I want, the account stays disconnected (or at least grey icon, mc-tool tells me that the account actually is connected). The protocol icon changes when I close accounts dialog and reopen it (it shows that the account is online) I'm not sure yet what causes the error, but it has the effect that no error-infobar appears when something went wrong, the status in accounts-dialog behaves strange (no presence icon in the infobar, protocol icon neither blinking nor active) and no contacts appear even if the account is connected. Although the account seems to be working (just got a spam massage from the faulty account - still no buddies in the contacts list) It looks like I have to restart empathy to fully use the account. Maybe its a MC issue, because this happens both with empathy 2.29.3 (from ubuntu repo) and empathy 2.29.4 from git.
*** Bug 605297 has been marked as a duplicate of this bug. ***
This should be fixed for 2.30.
http://git.collabora.co.uk/?p=user/kaserf/empathy.git;a=shortlog;h=refs/heads/creating-account-604628 this should fix the issue. the patch needs a review because I'm not sure if I have to disconnect to all those signals I connected to.
TpAccount is a GObject so you should use G_TYPE_OBJECT instead of G_TYPE_POINTER in the signal signature. What happen in that case: - An account already exists (or is created): we connect the signal - The account became invalid - The account became valid Are we connecting the signal twice?
*** Bug 606024 has been marked as a duplicate of this bug. ***
I've updated and rebased the branch... could you give it another look please? http://git.collabora.co.uk/?p=user/kaserf/empathy.git;a=shortlog;h=refs/heads/creating-account-604628
+ /* remove previously added handlers to prevent double invokes */ + g_signal_handlers_disconnect_by_func (account, + G_CALLBACK (main_window_connection_changed_cb), + window); Is that garanteed that this signal has always been connected before? IIRC, g_signal_handlers_disconnect_by_func will raise a warning if you try to disconnect an unconnected signal.
http://git.collabora.co.uk/?p=user/kaserf/empathy.git;a=shortlog;h=refs/heads/creating-account-604628 updated...
You should use GHashTableIter in main_window_destroy_cb. handler_id_pointer = g_hash_table_lookup ( + window->status_changed_handlers, account); Should be be: you can cast it right away using GPOINTER_TO_UINT and check if != 0. + guint handler_id; Should be gulong. + window->status_changed_handlers = g_hash_table_new_full (g_direct_hash, + g_direct_equal, + g_object_unref, + NULL); You don't ref the TpAccount so should not unref it when removing from the hash table. You should either ref it when adding to the hash table or pass NULL as key_destroy_func. Check what's best in this case.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.