[GSoC] GObjectification Summary

[Ankit Vani]

Hi Mark

On Thu, Nov 28, 2013 at 11:52 AM, Mark Doliner <mark at kingant.net> wrote:
> - The change to serv_set_info() in libpurple/server.c makes it no
> longer possible to short-circuit the function by returning non-zero
> from the account-setting-info signal. I'm fine with that but thought
> I'd point it out in case it was unintentional. There may well be
> better ways to accomplish this short circuiting now.

Ah, this was because I noticed that the "account-setting-info" signal has a
void return type. Thus, purple_signal_emit_return_1 would always have
returned NULL.

> - serv_got_chat_left() and serv_got_chat_in() in libpurple/server.c no
> longer return if the chat couldn't be found, so I think they will
> crash if called with a non-existent ID. I don't know if that ever
> happens, but it's a difference so I wanted to mention it.

You're right. I have no idea why I did that. o.O
Fixed.

> - Does the long “A brief explanation of the status API” text
> (https://developer.pidgin.im/doxygen/dev2.x.y/html/status_8h.html#_details)
> at the top of status.h still show up in the generated API docs? I
> think this comment was changed from /** to /*. I’m biased because I
> think I wrote this, but it seems like it would be useful information
> to plugin authors and I think it would be good if it remained in the
> API docs (it looks like the first paragraph is actually duplicated
> near the definitions for PurpleStatusType. That’s fine with me… I just
> want to make sure the info still exists in the API docs).

The first paragraph, regarding PurpleStatusType, is now associated with the
definition for PurpleStatusType, and the rest of the explanation is
basically a documentation for PurpleStatus. So moved it to the definition
of PurpleStatus.

Now the whole thing shows up in the generated docs with the appropriate
structures.

> - _purple_get_primitive_scores() exists in libpurple/status.c and is
> called from libpurple/presence.c. It’s not static and not declared in
> a .h file. Calling it from presence.c seems fine to me. It might be
> cleaner to add it to status.h, unless there’s a reason we don’t want
> to expose the function to the public.

The function returns a static array of primitive scores that nothing else
outside the statuses subsystem would require. This got a little ugly because
of the splitting of PurpleStatus and PurplePresence into two seperate files,
but I don't really see a point in exposing a function to the public, that
returns an array for which no documentation is available to the public.

Do you think I should make it public anyway?

Ankit