On Tue, 2014-05-20 at 11:07 +0200, Patrick Ohly wrote:
> Aren't you going to run into the same problem with a GObject-based
> proxies for these libical objects? The proxies are reference-counted,
> the libical objects are not, so they may go away before their proxies
> do. This would leave the prox
On Tue, 2014-05-20 at 11:07 +0200, Patrick Ohly wrote:
> Aren't you going to run into the same problem with a GObject-based
> proxies for these libical objects? The proxies are reference-counted,
> the libical objects are not, so they may go away before their proxies
> do. This would leave the prox
On Fri, 2014-05-16 at 19:28 +0200, Milan Crha wrote:
> 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
On Fri, 2014-05-16 at 19:28 +0200, Milan Crha wrote:
> 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
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,
On Thu, 2014-05-15 at 15:15 +0200, Milan Crha wrote:
> 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 "introsp
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.
rha
> 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
> > lib
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
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
> massi
On Wed, 2014-05-14 at 10:23 -0400, Matthew Barnes wrote:
> ...
> I suggest doing this as a stand-alone library -- libical-glib perhaps --
> ...
Hi,
right, my idea was (I should be more specific initially, I'm sorry) to
develop the standalone library with Will, like you proposed
libical-gl
On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote:
> 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 afrai
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 icalco
13 matches
Mail list logo
