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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers