adium: 1e356233: C89-ify. Use g_list_prepend instead of g...

[Zachary West]

On Tue, Apr 14, 2009 at 23:09, Ethan Blanton <elb at pidgin.im> wrote:
> Note that at one point in time we had this issue with the buddy list,
> and thus created a hash table that mirrors the list for the purpose of
> O(1) buddy lookups.  You might want to employ something similar -- and
> it might be usable upstream.

In ec7b74f84bcc99f27c6008c48cf322aaf0a7e12e (are revisions as useful
in monotone as they are in subversion?) I added a collate key (created
using g_utf8_collate_key()) for use when looking up the contacts in
the in_room GList. Almost the entirety of the performance issues with
the CB lookup was in g_utf8_collate(), so this significantly reduces
the time it takes to perform a purple_conv_chat_cb_find().

> If you're not confident pushing yourself, you can create a patch on
> the Pidgin trac, or come find one of us on IRC.  We'd be happy to
> help.  Reducing Adium's need for divergence with upstream libpurple is
> a goal I think we all share.

rekkanoryo and darkrain42 have been especially helpful in #adium-devl
with various libpurple or mtn-related questions. After a few lessons
in "hey, pull doesn't actually do an update also, I should stop making
a billion heads" I'm managing the mtn experience decently well.

I'm aiming for my changes to be accepted upstream, this area of code I
definitely do not want to have to deal with merging; I'm trying to
follow the coding style and glib requirements, so it shouldn't be too
bad to get it in into im.pidgin.pidgin. The major obstacle, I imagine,
is the struct changes for the PurpleConvChatBuddy collate_key and
attributes. I think at this point my changes are (barring any coding
style problems) ready; all of the kinks seem to have been worked out.

Zac West