Hello, maybe you noticed that we have a GSoC project for this year, to enable introspection for calendar part of evolution-data-server (libecal), which will make it usable for other languages as well.
Will is a student which will do the main work. The current problem is libical, its icalcomponent, enums and all other structures. I thought that we will be able to introspect this with simple boxed types, but it doesn't seem to be possible, thus the only option I can see is to massively change API of the calendar and define proxies for libical structures and enums. These proxies would be fully GObject-based, which might be a plus, I hope. I would, for example, define a GObject ICalComponent, which would have its i_cal_component_* API functions, mimic all the icalcomponent API, hiding the icalcomponent structure in the background. Such change will be huge, but more importantly it'll be an earthquake for anything using libecal (the ECalComponent would not use icalcomponent anymore, it would start using ICalComponent instead). Because of this earthquake, I would like to hear from others their opinion. Maybe we overlooked some option in introspection (there is preferred to create introspection based on code annotations, not to define them by hand), but I'm afraid the most of the projects like SyncEvolution, whether it'll be able to handle such change gracefully. I'd appreciate any opinion on the subject. Will, if you want to clarify anything from what I said, please do. I think we'll change the GSoC definition a bit, the task will be to create GObject-based API for libical library, and the followup work will be an integration into evolution of this new API. The followup means not for the GSoC. Let's talk about this off-list. 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