[Cogl] Cogl in Python

[Robert Bragg]

On Apr 8, 2012 3:33 AM, "Martin Owens" <doctormo at gmail.com> wrote:
>
> Hey Cogl Devs, (Just Robert and Neil?)
>
> Version: libcogl9 1.10.0 / gir1.2-cogl-1.0
>
> I'm using Cogl using gobject introspection, in conjunction with Clutter.
> But I'm having a problem using materials. Trying to do anything with
> Cogl objects causes a segfault, anything at all. Which means things
> like:
>
> m = ClutterTexture.get_cogl_material()
> Cogl.set_source(m)
>
> works ok, but:
>
> m.set_color4ub(255, 255, 255, 128)
> Cogl.Material.set_color4ub(m, 255, 255, 255, 128)
> print m
>
> Cause SEGFAULTS in Py_GetAttr, recursive_isinstance,  PyFile_WriteObject
> respectively.
>
> I did manage to workaround the SEGFAULT caused by cogl trying to unref
> the material after it had existed in python. Using the `del m` to remove
> it completely from the python namespace stops the odd duality.
>
> Literally looking at cogl-material in the wrong way causes it to blow up
> in ones face. I wonder what Clutter does that Cogl needs, maybe some
> sort of cooling rod ;-). Any ideas either working around these issues or
> trying to debug them using gdb, I'd be open to tracking through them.
>
> Best Regards, Martin Owens

Hi Martin,

We've only recently started looking at language bindings for Cogl so I'm
sorry that at the moment things aren't as simple as you might wish if you
aren't using C.

The thing is Cogl doesn't use gobject and so gobject intospection doesn't
really work for us to create language bindings. We have a few boxed types
really just to allow clutter's api to expose CoglMaterial and CoglMatrix
but it's not surprising to me that they fall apart if you give them a funny
look.

Because our api doesn't follow a lot of classic gobject api patterns I'm
not really sure how far we can get using gobject introspection for full
cogl bindings. I'm not sure that just shoe horning cogl through g-i by
creating dummy boxed types is going to have a great result. It might give
us bindings a bit quicker than doing them manually but I think perhaps they
would be a bad fit.

I was recently hoping to at least try and use the .gir data as a basis for
v8 bindings I was working on but really hit a brick wall with using the
scanner to get the data I wanted and at this point I'm thinking it will
just be simpler for us to use somthing like c2xml to extract an initial
markup for our api and extend that with annotations by hand for our
specific use cases.

Similarly for java bindings Neil found a pretty elegant way of marking up
the cogl api using java annotations for the front-end api and then the
compiler has some tricks to programatically access those annotations so we
can generate final bindings.

Since I also find it disapointing how locked away the gtk-doc annotations
we have in Cogl are currently I've recently been looking at doing a one-off
export of all our gtk-doc data into a simple xml schema which we can
combine with the markup of the prototypes and I'm interested to find out if
that would be good enough for us to then generate our bindings and html
documentation from.

I guess that this is perhaps not the answer you were hoping for but I hope
it gives some insight into what we've been thinking and toying with
recently.

If there is a strong interest in g-i based bindings specifically then
certainly we'd be open to ideas and help figuring out if it would be
workable, but at the moment I think perhaps Cogl breaks too many
assumptions about gobject based apis that it's possibly not the right tool
to try and use for us.

Kind regards,
- Robert

>
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/cogl/attachments/20120408/e99657cc/attachment.html>