[GSoC] GObjectification Summary

[Ankit Vani]

On Sun, Dec 8, 2013 at 12:51 AM, Mark Doliner <mark at kingant.net> wrote:
> I haven't looked at your .plugins branch yet. Have other people?
> Probably Gary and Ethan? In reality I think it will probably be at
> least a month before we collectively decide to merge it. I know it's a
> burden for you to keep it up to date with the changes in default. I'm
> under the impression that the changes in .plugins are less extensive
> than for soc.2013.gobjectification. Hopefully that makes maintenance
> it a little easier?

Yeah, the changes are less extensive than soc.2013.gobjectification. Whatever
changes I needed that did not directly require the new plugin and protocol
changes, I've added to soc.2013.gobjectification.

The obvious changes in the core are in the plugins and protocols subsystems.
The changes in the non-plugin codebase are mostly the replacement of
PurplePlugin and PurplePluginProtocolInfo (representing a prpl), with the
PurpleProtocol GObject. Changes in the plugins and protocols deal with the new
interfaces required by the new APIs.

Functional changes include the ability for one plugin to provide multiple
protocols (for example the jabber plugin is now a single plugin providing xmpp,
gtalk and facebook protocols). Protocols can optionally choose to subclass
some core types such as connections, roomlists, whiteboards, file transfers by
implementing the PurpleProtocolFactoryIface interface.

This branch also changes some of the prefs, which makes the new prefs not
compatible with the current branch. If needed, we will need to write code to
convert old prefs to new.

Also, making this branch work on Windows may take a bit of an effort (haven't
really looked into it much).

> Regarding gtk-doc vs. doxygen, I'm in favor of switching. It seems
> like gtk-doc has become the de facto standard for glib, gtk, gnome
> libraries. And as a developer I prefer the formatting/appearance of
> gtk-doc rather than doxygen. Personally I'd like to see us switch to
> gtk-doc regardless of your .plugins branch. Anyone object to this?
>
> Regarding the actual changes, it looks like you've done some work in
> your .plugins branch, but you're saying that every doc-style comment
> on all our functions and structs will need to change to use gtk-doc
> style? That change seems pretty straightforward... maybe we should
> make that change directly in the default branch and go ahead and check
> it in now? That way the .plugins branch contains only changes related
> to the plugin API.

I am in favour of this.

Switching to gtk-doc in the default branch will make things MUCH easier in the
plugins branch. That will also let me concentrate on making introspection work
without worrying about incoming changes from the default branch.

I have already set things up regarding gtk-doc in the plugins branch, so if
everyone agrees setting up stuff shouldn't be a problem.

Changing the documentation format in the code is the challenge. Any ideas on how
this can be automated? I had started working on a converter but its not finished
yet, and actually probably needs better planning..

Ankit