Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Thu, 2014-05-15 at 11:13 +0100, Philip Withnall wrote: > If you have some output showing the errors gobject-introspection gives > you when you run it on libical, I might be able to help you fix them. Hi, we tried to "introspect" libical inside libecal, basically by boxing libical types. The mos common error (warning) is about "Unresolved type"-s. These involve icaltimezone and icalcomponent. Both types are really defined as incomplete [1], but also out of the eds source. This marks related functions as unintrospectable. Another issue is with enums. Also the naming is not what gobject-introspection likes, there is no camel-case naming used in libical. I suppose half of the problem would be to solved by generating gir files directly in libical, but I'm afraid it'll not be enough, due to those incomplete types (the enums might be fixed by this, I guess). I've also quite limited knowledge of introspection, thus any help/guidance is more than welcome. Bye, Milan [1] typedef struct icalcomponent_impl icalcomponent; typedef struct _icaltimezoneicaltimezone; ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
Hey, If you have some output showing the errors gobject-introspection gives you when you run it on libical, I might be able to help you fix them. Philip On Wed, 2014-05-14 at 20:13 -0400, Miao Yu wrote: > Hi, > > > If I am not wrong, it is because the gobject-introspection has a hard > time in introspecting a third-party types, as those in libical. For > now, the only solution I can come up with is, as Milan said, to create > a proxy type for every type of libical which is used in EDS. After > that, I have to replace the libical types with the newly-created > introspectable proxy type in the API, which causes the disaster. And > this solution is, in nature, to write a introspectable wrapper for the > libical library. So that's why Milan want to put this under GObject so > that other applications can also use it instead of the libical. > > > And your solution is a nice way to fix that. Actually the focus can > also be put on the gobject-introspection. And gobject-introspection > can work with libical. Due to lack of experience, I cannot say which > one is better for now. But they can work to the same end. But if we > focus on the gobject-introspection, the introspection is not more > focusing solely on the gobjects since libical is a third-party > library. > > > Thank you. > > William Yu > > > > -Original Message- > From: Philip Withnall > To: Milan Crha > Cc: evolution-hackers ; will.yu > > Sent: Wed, May 14, 2014 1:16 pm > Subject: Re: [Evolution-hackers] Introspection enablement for libecal > - huge changes needed? > > On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote: > > 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. > > What exactly is the problem with introspecting libical? If it's a > fixable problem with gobject-introspection, I suspect it would be less > work (and a better overall outcome) if time were put into fixing > gobject-introspection so that libical *can* be introspected; rather than > putting more work into a wrapper library which will increase memory > overheads and require maintenance. > > Philip signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote: > 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. As said already, doing this as add-on of libical and then later taking advantage of it in EDS seems like the right approach. > 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. Would it be possible to keep the current EDS API around and just add the new introspectable API? > 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). ECalComponent would use a proxy of the original icalcomponent, right? If the introspection layer in libical has a way to convert to and from the original icalcomponent and the introspectable proxy, then ECalComponent could convert back and forth as needed, depending on which API the EDS client uses. > 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've made my peace with ABI and API changes in EDS ;-} I'm not happy about them, but I can handle them with a combination of ifdefs and compilation of backend shared objects on different Linux distros. Just give me enough and explicit warning beforehand. If an API change can't be avoided, then don't let SyncEvolution hold you back. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
