GObjectification projects proposal, and GObject-based plugins API
a at nevitus.org
Wed May 1 16:14:21 EDT 2013
I am working on a proposal for GSoC for GObjectification projects.
Pidgin has been wanting to adopt GObjects for quite some time now, and the
very interesting detachable sessions project can be made usable when this feat
However, the gobjectification branches seem to be untouched for ages.
Since this is an important milestone for libpurple/pidgin/finch, I wish to work
on it and get involved with the pidgin community.
What my proposal will involve:
- Gobjectification of some core structures of libpurple, pidgin and finch
Constructs such as the buddy list and conversation interface will be
gobjectified. A significant amount of code redesigning around the GObject
will be done along with this. I will be working alongside the community and
my mentor for decisions regarding redesigning crucial bits.
- Remodeling the plugin API around GObject (coming to this in a bit)
The current plugin API will be replaced with an API based on GObjects.
There are a number of ways this can be implemented. I have discussed these
Some existing plugins will be ported to the new plugin API.
- Protocol plugins will be an implementations of a protocol interface
A GObject-based interface will be created for protocols. The protocol
plugins will implement PurpleProtocolIface, which will provide a common
interface to work with different protocols.
Some existing protocols will be ported to the new protocol API.
For the new plugin API, I have determined the following possible ways to do
(1) The current PurplePlugin becomes a GObject, and all plugins become objects
This approach is the easiest to implement since it is most similar to what
is currently implemented.
(2) The current PurplePlugin becomes a GObject, and all plugins define their
own type deriving from PurplePlugin.
This approach gives plugins freedom to define its own members and
extension points for other plugins. This seems to be a more intuitive way
of dealing with plugins for a gobjectified plugin system.
It will require a little more work in porting the existing plugins to
the new API.
(3) Use a plugin API library such as libpeas.
libpeas is an existing gobject-based plugins engine, and works in the same
manner as (2). It supports multiple extension points and on demand (lazy)
programming language support for C, Python and JS.
It will require the most changes to the current plugin API, the existing
plugin code and also the directory structure - every plugin needs it's own
directory with a .plugin file that declares it's information (such as
name, author etc).
I would like to gain insight into what the developers think about this, what
you would prefer and why.
It would also be kind of you to provide feedback and other suggestions so that
I can improve my proposal.
-- Ankit Vani (ankitkv)
More information about the Devel