[GSoC] GObjectification progress as of July 22, 2013

[Elliott Sales de Andrade]

Hi Ankit,

On 22 July 2013 17:42, Ankit Vani <a at nevitus.org> wrote:
> Buddy List
> ----------
>
> PurpleBlistNodeFlags has been removed. For a long time, only one flag has
> existed (ie. PURPLE_BLIST_NODE_FLAG_NO_SAVE). I have converted this to a
> property of PurpleBListNode, and can be used with
> purple_blist_node_set_dont_save(), purple_blist_node_get_dont_save().
>

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.

> purple_blist_ is the buddy list subsystem API and purple_buddy_list_ are
> functions for the PurpleBuddyList object. Although as of right now, the only
> purple_buddy_list_ function is purple_buddy_list_get_type(), that returns the
> GType for the object. However, the function purple_get_blist() has been renamed
> appropriately to purple_blist_get_buddy_list().
>

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

>
> Connections
> -----------
>

> When refactoring the codebase to use the GObject-based connection API, I had run
> into some issues with the jabber protocol.
> I would like to discuss these issues to make sure they are handled properly.
> I would appreciate insight and suggestions.
>
> 1. In libpurple/protocols/jabber/jabber.c
>    Line: http://hg.pidgin.im/pidgin/main/file/3b8ce83bac96/libpurple/protocols/jabber/jabber.c#l1378
>    Here, the member wants_to_die of a connection is set directly. I believe this
>    setting this directly should be avoided. And because the member wants_to_die
>    is now private due to GObjectification, it cannot be accessed directly even
>    if we wanted to. At first, I did not want to add a function to do something
>    like this as it sounded.. not right.
>
>    However, for the time being, I added the function
>    purple_connection_disable_reconnection(), which does what is expected from
>    it's name. It is intended for protocols to handle user registration due to
>    queries, which as of now is only done by jabber.
>

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.

> 2. In libpurple/protocols/jabber/parser.c
>    Line: http://hg.pidgin.im/pidgin/main/file/3b8ce83bac96/libpurple/protocols/jabber/parser.c#l311
>    Here, the member disconnect_timeout of a connection is accessed directly. I
>    don't think this member should be accessed directly at all, under any
>    circumstance. Also, the check does seem a little unnecessary, but I haven't
>    spent enough time with protocols to know for sure. No other protocol does
>    this.
>
>    For now, I have disabled that bit with #if 0. Please let me know if this
>    check if really necessary, and if so, I would appreciate some help.
>

As I understand it, that check is a "Did we call
purple_connection_error[_reason] already?" test.

The code in the if is a "we'll try this for old servers that can't
identify themselves as old servers". So if we've already connected
using the new version and run into an error because a bad password or
something, then we don't need to run the code in the if. But if we
haven't fully connected, then as a last resort, we'll try the old
server code and see if it works.

I'm sure there's a better way to write the condition somehow.

> Some other changes
> ------------------
>
> I will be starting with redesigning the plugin API next, after which I will be
> working on the protocol API. Please let me know if you have suggestions or ideas
> regarding how I should pursue these.
>

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

> Any feedback or suggestions for changes regarding my progress so far would be
> appreciated. :)
>
>                                                                          - Ankit
>



-- 
Elliott aka QuLogic
Pidgin developer