[GSoC] GObjectification Summary

[Mark Doliner]

To anyone else reviewing this: You don't really need to look through
the PRPLs or plugins or really even finch or pidgin unless you really
want to. The changes in those files are pretty straightforward--mostly
renaming and minor changes to keep things working with the changes in
the code in libpurple

To Ankit: I still think this looks real good. I still think we should
merge it sometime. Personally I'd like to spend a little more time
(I'm hoping less than 10 days (I'll be gone for 4 of them)) looking at
the changes in the core, but if a few other people have already
finished reading through the changes then don't let me stop us from
merging.

Some more feedback:
- Do non-privileged trac users have access to
https://developer.pidgin.im/newticket? We previously linked to
simpleticket. In doc/finch.1.in and doc/pidgin.1.in
- pidgin_permit_added_removed() and pidgin_deny_added_removed() should
either be listed in a header file or changed to only be referenced
from a single file and made static. It looks like they're used as a
ui_op... maybe they could be accessed that way?
- Not important, but we should fix the name of the #ifndef for
libpurple/finch/gntxfer.h libpurple/protocols/gg/blist.h
pidgin/gtkxfer.h
- Need to address FIXME comment in libpurple/protocols/jabber/jutil.c?
- Need to address FIXME comment at the bottom of
libpurple/protocols/jabber/parser.c?
- A single file-wide static conn_close_timeout doesn't handle multiple
jabber accounts correctly in libpurple/protocols/jabber/jabber.c
because there is only one copy of the static var being used by
multiple accounts. Though, I think this code is no worse than it was
before. In any case we should at least add a TODO comment to fix this.
- Need to do anything about the #if 0'ed code in
libpurple/plugins/tcl/tcl_signals.c?
- Need to do anything about the #if 0'ed code in
libpurple/plugins/perl/perl-common.c purple_perl_sv_from_vargs()?
- Need to do anything about the #if 0'ed code in
libpurple/plugins/perl/perl-handlers.c perl_signal_cb()?
- Our example plugins shouldn't #include <internal.h>, right? I guess
it doesn't matter if the code is in our tree. Even better would be for
these things to live in a separate repo or package outside our tree,
and for us to distribute simple autoconf and automake files. (Some
files that include internal.h that maybe shouldn't:
libpurple/plugins/dbus-example.c libpurple/plugins/debug_example.c
libpurple/plugins/helloworld.c libpurple/plugins/notify_example.c)

In an earlier email you said:
"These entities are temporarily GBoxed, with a TODO mentioning so in their
purple_entity_get_type() function's documentation, and should eventually be
converted to GObjects:
 GBoxed
  +----PurpleCertificatePool
  +----PurpleSavedStatus
  +----PurpleStoredImage
  +----PurpleLog
  +----PurpleXfer
  +----PurplePlugin"

Do we need to do anything about these before merging? Or after merging?