[GSoC] GObjectification progress as of July 22, 2013

Ankit Vani a at nevitus.org
Sat Jul 27 07:13:48 EDT 2013


Hi Elliott,
Thanks for your feedback :)

On 27 July 2013 05:24, Elliott Sales de Andrade <qulogic at pidgin.im> wrote:
> I'm not sure I agree with that name. First, it's a contraction, which
> doesn't look right. Second, it's a negative (which is a problem with
> the original flag as well.)
>
> Instead, I'd go with either "saveable" (default: TRUE) or "transient"
> (default: FALSE). I'm leaning more towards the latter, though it
> depends on what connotation you wish to imply.

I renamed "dont_save" to "transient". purple_blist_node_set_transient() sets the
transient property, and purple_blist_node_is_transient() can be used for
checking it.

> There was/is a plan to support only one buddy list. Not sure how that
> fits in with that function.

Yes, I know. I guess what I was trying to explain was the distinction between
the purple_blist_ API for the subsystem, which operates on the singleton buddy
list, against 'buddy_list' to refer to the API that relates to the type
PurpleBuddyList (thus only the function that returns the GType for the object
come under this).

For example, in case of accounts, you have the purple_account_ API that does
things for objects of type PurpleAccount, whereas the subsystem purple_accounts_
API operates on these accounts.

purple_blist_get_buddy_list() is more of just a clarification, that fits the
naming convention.

> Instead of "don't reconnect", we should probably define something that
> encodes the result of registration. Something along the lines of
> "failed to register user", "registered and updated settings, please
> reconnect", or "registered and using this connection to continue",
> etc.

Generally, for registrations, wants_to_die for a connection is set before
calling the protocol's registration function. However, in that case for jabber,
it is a registration triggered by a query (as far as I have understood), thus
making it a unique case.

I have removed purple_connection_disable_reconnection(), and have used
purple_connection_error() instead, with a description that asks for
reconnection. In case of pidgin, I think this behaves just the way it did
before.

> I believe Gary suggested using his GPlugin code for that. You should
> probably talk to him if you haven't already.

Yes, Gary, Ethan and me have discussed GPlugin and we have decided to go
forward with using GPlugin in our new plugin API. :)

                                                                         - Ankit



More information about the Devel mailing list