Remove obsolete contact-list-{store,view} Hourrah \o/ https://bugzilla.gnome.org/show_bug.cgi?id=663387
Use _unref instead of _free _destroy when possible.unref Replace g_(ptr_)array_free (foo, TRUE) and g_hash_table_destroy with respectively g_(ptr_)array_unref (foo) and g_hash_table_unref. I used this command to generate this patch: for f in `find -name "*.c"`; do sed -i $f -re 's/g_ptr_array_free \(([^ ,]+), TRUE\)/g_ptr_array_unref \(\1\)/'; done See Danielle's blog for explanation of possible bug _free can do: http://blogs.gnome.org/danni/2011/11/16/mistakes-with-g_value_set_boxed/
ensure that contact_list_store_contact_active_cb isn't called after the store destruction This is an exact port of similar code from empathy-individual-store. https://bugzilla.gnome.org/show_bug.cgi?id=662211
contact_list_store_dispose: unset the timer ids https://bugzilla.gnome.org/show_bug.cgi?id=662211
contact-list-store: stop tracking favourite contacts https://bugzilla.gnome.org/show_bug.cgi?id=661489
contact-list-store: remove 'fake group' code This store is only used for MUC members which doesn't use these fake groups. Actually we could drop all the group code but it would probably be easier to completely rewrite the way we display MUC members. https://bugzilla.gnome.org/show_bug.cgi?id=661489
Remove unused variables [-Werror=unused-but-set-variable] https://bugzilla.gnome.org/show_bug.cgi?id=658650
contact-list-store: store GtkTreeIter rather than GtkTreeRowReference in the cache GtkTreeRowReference keeps a ref on the store introducing a ref cycle. https://bugzilla.gnome.org/show_bug.cgi?id=658650
contact_list_store_remove_contact: ensure that the store stays alive during the process https://bugzilla.gnome.org/show_bug.cgi?id=658644
coding style fix
contact list: optimize loading contacts The previous algorithm was O(n^2) with the number of contacts. Each contact can be in several groups, so when a contact is added or updated, we iterated over all the contact list to find the rows representing the contact. When connecting to an account and getting all the contacts, this was too slow. The groups are stored in the GtkTreeStore and suffer from the same problem: to look for a group, it needed to iterate on all contacts. The new algorithm maintains a hash from the contact to the list of rows representing it, and another hash from the group to the row representing it. On Empathy 2.30.2 when tested on MeeGo with 300 contacts, loading the contacts is faster: roughly 9 seconds before the patch, 3 seconds after. On Empathy 3.1.5, it seems to load in background so I don't know how to measure the time lost in GtkTreeStore. But before the patch, GProf says 23% is lost in individual_store_find_contact_foreach(), and after the patch it is not visible anymore. And "time" says we win 5s of CPU when starting+quitting Empathy: Before the patch: After the patch: real 0m23.485s real 0m23.460s user 0m13.805s user 0m8.305s sys 0m0.308s sys 0m0.316s https://bugzilla.gnome.org/show_bug.cgi?id=657086
EmpathyTpChat: inherit from TpTextChannel (#650554)
contact_list_store_chat_state_changed_cb(): tidy This doesn't fix bgo#647891, but I think it makes the loop clearer. Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Fix warnings from GCC 4.6 about variables that are set but not used.
Display typing icon in MUC contact-list Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=609419
Fix missing entries in switch statements Added missing default cases and missing enum cases.
Merge EmpathyContact:name and *_set_alias() to EmpathyContact:alias The "name" API was a relic of Gossip.
Rely on compare_separator_and_groups when either A or B isn't a contact We can't rely on the fact that compare_separator_and_groups only returns 0 in the case it compares two contacts. But we can completely rely on its result if we give it at least one non-contact.
Now that we depend on the logger always enable favourite contact support
Pick the right sort function early We can't assume that the group and seperator sorting function never returns 0, so don't use that to imply that both A and B are contacts. Instead just check if A and B are contacts...