old rev: 811d6e22fc676b5d2f87ff0d8fff750662e4bc7b

new rev: 2ef380ad3a75f214245ca5e1a34e7fc3d4e23914


Notes:


I know you're updating finch because you're using it. But i don't think I ever explicitly told you that you don't need to worry about the ui's. You're scope is libpurple, and libpurple alone. This only includes, libpurple, the protocol plugins, and perhaps the standard plugins. This does not include the plugin loaders, the ui's or any of the gtk or gnt plugins.

I need to run you through delegators and member methods, which for some strange reason I've been calling class methods. I understand completely now why you're getting *REALLY* confused about this.

There's quite a few instances where theres some uber long lines. We may want to use some variables to make these a bit more readable. I'll point this out where I notice it.

I'm using a mix of line numbers and function names. It's pretty sparadic, mostly when i don't want to count a ton of lines from the start of the hunk :)


Fix notes:


0f8b96e8a4baefb1049aee2d250f30cd41ecd68d

Fixed some casting (PurpleBlistNode? *) to PURPLE_BLIST_NODE, there might be more, there probably are ;)


Files:


libpurple/blist-node.h

  • doxygen comments are incorrect

libpurple/buddy.h

  • doxygen comments are incorrect

libpurple/chat.h

  • doxygen comments are incorrect

libpurple/contact.h

  • doxygen comments are incorrect

libpurple/group.h

  • doxygen comments are incorrect

libpurple/blist-node.c

  • purple_blist_node_(add|remove)_node needs lots of help. We'll cover this indepth, and it should give you a good understand of it and unconfuse you :)
  • purple_blist_node_finalize shouldn't be doing any unrefs, that'll be covered by the subclasses (we'll go over this indepth during the member methods discussion)
  • purple_blist_node_init: we may want to make settings a property, but right now it's okay where it is.

libpurple/blist.c

libpurple/blist.h

  • line 476 the while should be able to be removed, since everything should be holding a reference to the buddy if they need it.
  • purple_buddy_class_init: the properties shouldn't have the names and descriptions marked for translation (right now). We need to determine if we're going to do it as a project, and if so, how we're going to implement it.
  • purple_buddy_init: call new_node with PURPLE_BLIST_NODE(buddy)

libpurple/buddyicon.c

  • line 863, we'll probably want to change this to if(!PURPLE_IS_BUDDY(node)) { unless i'm completely misreading this.
  • line 948, same as above

libpurple/contact.c

  • line 260 needs a space before the ==
  • purple_contact_remove_buddy, we'll cover teh ops->update in our member method discussion.
  • line 321 should be using PURPLE_BLIST_NODE(contact), but should be removed. All we need to do is drop the ops->new_node method in purple_blist_node_init and all of the children will automatically do it. Actually, it'll get triggered at the wrong time, so it has to stay in the instance_init or we need to create a signal or helper function.

libpurple/group.c

  • struct members should be hidden
  • purple_group_get_accounts, replace typecasts with their PURPLE_FOO macros.
  • the name property should be G_PARAM_CONSTRUCT, not G_PARAM_CONSTRUCT_ONLY
  • purple_group_init should be using the private structure

libpurple/plugins/perl/common/BuddyList.xs

  • this will need to be fixed, but is out of your scope.

libpurple/plugins/perl/common/module.h

  • this will need to be fixed, but is out of your scope.

libpurple/protocols/bonjour/bonjour_ft.c

  • line 862 uber line syndrome

libpurple/protocols/jabber/roster.c

  • line 467 uber line syndrome

libpurple/protocols/myspace/myspace.c

  • line 395 uber line syndrome

libpurple/protocols/silc/buddy.c

  • line 1468 uber line syndrome
  • line 1534 uber line syndrome

libpurple/protocols/zephyr/zephyr.c

  • line 815 uber line syndrome
  • line 817 uber line syndrome
  • line 1197 uber line syndrome
  • line 1199 uber line syndrome
Last modified 9 years ago Last modified on 07/15/09 22:02:02
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!