[GSoC] GObjectification Summary

[Ankit Vani]

On Mon, Dec 2, 2013 at 9:20 AM, Mark Doliner <mark at kingant.net> wrote:
> - purple_chat_conversation_set_property() doesn't allow setting TOPIC
> or TOPIC_WHO. Should it?

Our implementation of setting the chat topic via
purple_chat_conversation_set_topic requires both the topic and the topic setter,
which then emits the signal "chat-topic-changed" with both these arguments.
Allowing the setting of only one of the properties would break this. One way
would be for both properties to emit "chat-topic-changed" on being changed with
the unchanged value being passed as-is. But that would emit the signal twice,
which would show two topic changes in the UI, of which the first one will be
incorrect.

> - Same question for BUDDY_PROP_PRESENCE in purple_buddy_set_property().

I made presence a read-only property, since I didn't find any place in the
codebase where we would need to change it. Also, we did not have an API for
setting the presence before either. ie. we didn't have
purple_buddy_set_presence, but we did have a purple_buddy_get_presence.
Currently, a buddy presence is created during buddy construction (depending on
the account), and destroyed when the buddy is destroyed.

Please let me know if we would need to be able to change the presence object of
a buddy.

> - In purple_buddy_set_property(), should we call
> purple_buddy_set_name() for BUDDY_PROP_NAME? It seems like the current
> version won't cause blist.xml to be re-written to disk (and maybe UI
> won't get updated?)
>
> - Same question for BUDDY_PROP_LOCAL_ALIAS and purple_buddy_set_local_alias().
>
> - Same question for GROUP_PROP_NAME and purple_group_set_name().
>
> - Same question CHAT_PROP_ALIAS and purple_chat_set_alias().

Ah, I see the problem.. Those properties were made to directly change the
members because they are set during the construction of the node -- where we
don't want the UI to get involved, since UI does its thing via ops->new_node
once the node is ready.

Instead of converting these to construct-only, I have now added
'is_constructed' private members to determine how set_property should be handled
for those cases.

On Mon, Dec 2, 2013 at 9:32 AM, Ethan Blanton <elb at pidgin.im> wrote:
> Mark Doliner spake unto us the following wisdom:
>> > 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?
>>
>> Hmm. I guess this question doesn't have an obvious answer. I see your
>> point about not wanting to make the functions public., but I'm also
>> not a fan of calling functions in other files when those functions
>> aren't listed in a header file. It feels messy. I guess I mildly
>> prefer listing them in our public header file, even if that exposes
>> them to third parties. But please don't let me be the final decider.
>> Please use your own judgement and/or check with Ethan or other Pidgin
>> devs.
>
> Declaring it in libpurple/internal.h seems like the correct answer
> here.  I think it's pretty clear that anything in libpurple/internal.h
> isn't part of our contract.  There are a number of other _functions
> there already.

Done!

On Thu, Dec 5, 2013 at 1:16 PM, Mark Doliner <mark at kingant.net> wrote:
> I haven't heard any objections, so let's merge this to main!
> Specifically, let's merge
> https://hg.pidgin.im/soc/2013/ankitkv/gobjectification/ branch
> soc.2013.gobjectification to https://hg.pidgin.im/pidgin/main/ branch
> default. I expect it will be an easy merge since you've been keeping
> your branch up to date.
>
> Ankit: Do you have any interest yourself in doing it? Or would you
> rather someone else do it? I just gave you commit access to
> /pidgin/**, so if you want to do the merge then by all means go for
> it.

Yay! Yes, I would love to do it myself :p
Will do it as soon as I send this mail.

After the merge, how do I go about further soc.2013.gobjectification changes?
Do I make them directly on the default branch, or do I continue working on
soc.2013.gobjectification? If directly on default, then should I close the
soc.2013.gobjectification branch?

By the way, most of the GPlugin issues with the
soc.2013.gobjectification.plugins branch have been resolved, but not all. As for
the pidgin side of things, we will be needing a huge documentation change
(change from doxygen to gtk-doc). Everything is already set up, only changing
the format of the actual comments is left. This, as I had mentioned before, I
will do in the end when everything is functionally ready so that merges from
default aren't a pain.


> And of course
> please don't do anything crazy like commit backdoors or turn Pidgin
> into a virus.

Aw :(