old rev: 811d6e22fc676b5d2f87ff0d8fff750662e4bc7b

new rev: 2ef380ad3a75f214245ca5e1a34e7fc3d4e23914


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:


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



  • doxygen comments are incorrect


  • doxygen comments are incorrect


  • doxygen comments are incorrect


  • doxygen comments are incorrect


  • doxygen comments are incorrect


  • 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.



  • 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)


  • 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


  • 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.


  • 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


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


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


  • line 862 uber line syndrome


  • line 467 uber line syndrome


  • line 395 uber line syndrome


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


  • 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!