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

---

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

finch/gntblist.c

• the comment starting on lines 238-239 can be deleted
• line 1395 should be using PURPLE_BUDDY(node) and not typecasting directly (glib will actually check the instance for us if we use the macro)
• line 1398 should be using PURPLE_GROUP(node) and not typecasting directly
• line 1676 nuke the comment and it's contents
• line 2387:2388 use PURPLE_CHAT(n[12]) (see above)
• line 2390:2391 use PURPLE_BUDDY(n[12]) (see above)
• line 2393:2394 use PURPLE_CONTACT(n[12]) (see above)
• line 2424:2425 use PURPLE_BUDDY(n[12]) (see above)
• line 2467:2468 use PURPLE_BUDDY(n[12]) (see above)

finch/plugins/grouping.c

• line 36 needs to be a subclass or a group instances with the names "online" and "offline". (out of scope)
• line 54 should be using PURPLE_CONTACT(node) (see above)
• line 59 use PURPLE_BUDDY(node) (see above)
• line 67 use PURPLE_CHAT(node) (see above)
• line 110 online and offline haven't been initialized yet
• line 115 online hasn't been initialized yet
• line 137 needs to be a subclass, or a group instance with the name "meebo" (out of scope)
• line 269 looks like creating a group node instead _should_ be ok. (out of scope)
• line 288 should be ok for now, but should be using PURPLE_IS_BLIST_NODE (out of scope)

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

• line 544 use PURPLE_GROUP(cnode->parent) (see above)
• line 613 lose the (PurpleBlistNode? *) typecast
• line 727 should use purple_blist_node_remove_node (we'll cover this in the delegator discussion)
• line 1131 lose the (PurpleBlistNode? *) typecast
• line 1221 lose the (PurpleBlistNode? *) typecast
• line 1578 should be able to die

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

pidgin/gtkblist.c (out of scope)

• line 1513 uber line syndrome
• line 1519 uber line syndrome
• line 1554 uber line syndrome
• line 1582 uber line syndrome
• line 1639 uber line syndrome
• line 2010 uber line syndrome
• line 2356 uber line syndrome
• lines 2665:2666 uber line syndromes
• line 2776 uber line syndrome
• line 3820 uber line syndrome
• line 3822 uber line syndrome
• line 3830 uber line syndrome
• line 3860 uber line syndrome
• line 4056 uber line syndrome
• grown tired of recording these... especially since they're out of scope