Some aspects of the GObjectification approach

Elliott Sales de Andrade qulogic at
Sun Jun 2 18:31:17 EDT 2013

On 1 June 2013 17:23,  <gillou.ray at> wrote:
> On Sun, 2 Jun 2013 00:43:56 +0530
> Ankit Vani <a at> wrote:
>> In my proposal, I suggested using PurpleObject as a base to all purple
>> classes. But PurpleObject doesn't really buy us anything and wastes
>> memory instead. The objects can inherit GObject directly and any
>> mechanism that would require PurpleObject would just be more flexible
>> by using GObjects instead.
> Hmm in my detachable sessions project I’ve been using PurpleObjects as a
> mean to make our objects DBus-capable. That is to say, to add DBus init
> methods and to allow binding DBus methods, for every object [1]. Now
> you’re mentioning this, I think too this is a waste of memory since
> probably not every object is gonna need to show up on DBus. In theory it
> would make more sense to have this DBus stuff defined into an
> interface, only implemented by the relevant DBus-interested objects. In
> practice I never played with gobject’s interfaces so I’m not 100% sure
> using interfaces will be fine.

Is it not possible to use GObject introspection to hook this up? I'm
not sure which one you used, but it looks like both dbus-glib and its
replacement GDbus can use introspection data of some sort to create
their DBus equivalents. Maybe it's only DBus introspection data

> I’d say go on and remove PurpleObjects. After all switching from
> PurpleObject inherited to GObject inherited objects is a matter of
> search-and-replace, so it’s not a big deal to revert if you change your
> mind afterwards.
> [1]
>                 — gillux

Elliott aka QuLogic
Pidgin developer

More information about the Devel mailing list