Re: custom functions in introspection typelibs

["Colin Walters" <walters verbum org>]

On Sat, Sep 27, 2008 at 6:54 PM, Havoc Pennington <hp pobox com> wrote:
>
> For overrides that make sense for all bindings, I think we should
> consider gir-repository to be a "shared binding" or shared piece of
> all bindings, and include the overrides there.

Yeah.

> I don't know which module these things should be in, but I think they
> are useful to have in the "G" stack. Aside from bindings, an example
> use-case is writing a dynamic marshaler to replace glib-genmarshal
> static marshalers.

For that we can just have glib depend on FFI and start ignoring the
marshaler argument to g_signal_new.  We don't need to expose a public
"GFFI" API for that, no?

> It is not a big deal for any binding to cut-and-paste from
> gobject-introspection probably, but I think as soon as a few bindings
> are using this, or some non-binding use is found, there will be demand
> to factor them out and stick them someplace.

If pybank continues to not be ctypes based or if there is some other
non-binding use (though I have trouble thinking of one) I agree it
would make sense to have in g-i.

> They probably do belong in glib proper, not gobject-introspection.

That would create a circular dependency.

> One counterargument is that there's substantial code to write to go
> from a GIFieldInfo to these language-specific FFI layers. Something
> like:

True, I know the JNA structure and union handling is not trivial.  I
haven't looked at ctypes in depth.

> I like the inject solution but not the libjscustom.so ... this means
> the js bindings would conflict with gir-repository (both would be
> installing Clutter.gir and the Clutter typelib).
>
> I think the injection and the custom .so should be in gir-repository,
> and that the custom .so should be per-typelib to avoid extra
> dependencies. (i.e. the custom .so for GLib should not drag in GTK)

Ok.  I guess this would mean taking the existing files like
gtk-x11-2.0.c and adding code, compiling and installing them.

> Note, though, libffi itself doesn't have this afaict. It looks to me
> like struct field access (and struct size determination) have to be
> coded from scratch, or at least massaged into existence by
> de-pythonizing python ctypes code or some other existing codebase.

Right, I meant a "complete FFI layer" rather than just libffi.

> So in short there's no existing nice C library that does this. It
> makes sense to me to include it in glib or gobject-introspection or
> something.

I'm not sure that it's going to be useful for C, but if having struct
access code in g-i is easier I'm not opposed.

> The specific example here (passing pixbuf pixels without copying them
> through a non-C string) I think is probably common to all bindings and
> is effectively needed to make the Clutter API practical outside of C.
> I'm not sure it should be in gir-repository without getting Clutter
> upstream agreement to eventually include it, but given that agreement,
> including it makes sense.

Oh, is this is just because Clutter doesn't currently depend on
GdkPixbuf?  I'm not sure we want to be changing the dependencies in
gir-repository if that's the case.