pidgin.yaz: log

log

less more | rev 22407: (0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip

age	author	description
Wed, 05 Mar 2008 09:40:16 +0000	Mark Doliner	These things are always NULL, so these if statements are never triggered
Wed, 05 Mar 2008 00:26:44 +0000	Evan Schoenberg	Fixed bug in which Yahoo contacts were erroneously considered to be blocked,
Tue, 04 Mar 2008 23:53:44 +0000	Evan Schoenberg	Just write out the buddy icon file; there's no need to check to see if it exists. This is for the cache, and if the blist.xml gets out of sync with the cache on disk (for example, because the user moves the blist.xml file out of the way), the existing code will never update the cached icon again.
Tue, 04 Mar 2008 18:50:16 +0000	Evan Schoenberg	Prefer more available resources to less available ones when priorities are the same. Fixes #5079.
Tue, 04 Mar 2008 16:23:07 +0000	Stu Tomlinson	Correct documentation in --help and man page for -l command line option.
Tue, 04 Mar 2008 09:41:44 +0000	Mark Doliner	Move the status note parsing into a separate function, which I think
Tue, 04 Mar 2008 00:11:22 +0000	Evan Schoenberg	When purple_buddy_icons_set_account_icon() is called, it unrefs the old PurpleStoredImage and refs the new one. Previously, it notified the prpl of the change in the buddy icon before updating pointer_icon_cache, which meant that if the prpl then called purple_buddy_icons_find_account_icon() it would get the old PurpleStoredImage (which is at this point not only old but also a pointer to invalid memory if unref'ing it caused it to be destroyed). This happens in jabber_set_info() as of 2.4.0, causing a crash when setting no-buddy-icon for an account after it has previously had an icon. I think this also means that XMPP accounts in 2.4.0 will also always set serverside the last icon set, not the current one, when changing icons, but I didn't test that.

less more | rev 22407: (0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip