What to do with the gobjectification branch

[Sadrul Habib Chowdhury]

Hi! I haven't done much in pidgin land in the last couple of years,
but I do have opinions!

On Mon, Jan 21, 2013 at 4:14 PM, Richard Laager <rlaager at wiktel.com> wrote:
> On Fri, 2013-01-18 at 23:11 -0800, Mark Doliner wrote:
>>   - Change one struct at a time (preferably directly in main.  Or, if
>> it's done in a separate branch, it should be done in a short amount of
>> time (a few days) and merged into main as soon as possible.)
>
> This requires all the struct hiding work to be done. That doesn't appear
> to be the case on the "default" branch currently.

Perhaps the struct hiding can start with some #ifdef hackery:

    typedef struct _PurpleConversation PurpleConversation;

    #if defined(PURPLE_INTERNAL_STRUCTS)
    struct _PurpleConversation {
        ...
    };
    #endif

and -DPURPLE_INTERNAL_STRUCTS gets added to the compile commands from autofoo.

I seem to remember someone else floated this idea a while back (and I
almost seem to remember we also started doing this in certain places
... but can't find any relevant code)? But this would allow
incremental struct-hiding in the codebase, without exposing the
structs to external (third-party) plugins.

I did some work on the struct-hiding and gobjectification at some
point; and that work is rather tedious. To make progress on these
areas, the developer needs to be somewhat familiar with the pidgin
codebase and gobject type subtleties (among other things), and needs
to enjoy doing things that don't make any visible difference, or offer
instant gratification. It may be difficult to find someone like this
(which I think is one of the main reasons for the lack of progress in
the gobjectification branch) ... unless maybe they are getting paid to
do this ... summer of code candidate?

Sadrul