Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?

[Milan Crha <mcrha redhat com>]

On Fri, 2014-05-16 at 08:56 +0100, Philip Withnall wrote:
> So Fabiano asked about this in #gnome-hackers yesterday, and I think the
> conclusion was to do something similar to what's done in Cairo: add the
> G_DEFINE_BOXED_TYPE and glib-mkenums boilerplate somewhere (either
> directly in libical, or in a small libical-glib library which otherwise
> does *not* wrap the libical API). I think gobject-introspection will
> need fixing to support non-standard names for APIs and types.

        Hi,
that was my idea too, the project seemed extensive, but not too
complicated. Nonetheless, Will found an issue with libical memory
management quite quickly and I recalled it when I was talking to him
yesterday.

The main problem is that the API returns pointers which are part of the
structure that you ask the value of it - like when you ask for a
subcomponent of an icalcomponent. If it exists, you get a child of the
parent component. This makes a disaster due to the unpredictable memory
management in python or javascript (introspection-using languages in
general?). The libecal uses this libical behaviour too. As an example,
if you ask for an alarm of an ECalComponent, then you receive a new
structure which holds a libical structure, which is part of the
ECalComponent (icalcomponent of it). Any changes done through this
structure are immediately propagated into the parent's ECalComponent,
aka there is no "save" involved. If you free ECalComponent before the
alarm structure, then the free of the alarm structure causes a crash. As
you cannot influence the memory-free time in python... and even if it
would be possible, then we cannot expect from the introspection
interface users (developers) to tweak their code in a way they are not
used to (like making some memory/variable management on their own).

That's basically the reason why we'll need a real GObject-s, which will
hide this behaviour and will make it simpler in the introspection
languages to play with ICalComponent objects (proposal for the name). As
a side-effect we also get a nice gtk-doc developer reference, which
might be a real plus.

The more I think of this, the more I'm convinced that there will be some
pattern which will Will be able to use and generate all the
introspectable API with some smart scripts from public libical headers,
which will also make sure that any future API changes in libical will be
easily noticed. Something similar to gdbus-codegen, with an input file
for function's documentation. It still needs more thinking and testing
and so on, I only offer the idea to Will sooner, thus he'll have time to
think of it.
        Bye,
        Milan