On Apr 8, 2012 3:33 AM, "Martin Owens" <<a href="mailto:doctormo@gmail.com">doctormo@gmail.com</a>> 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 > <a href="mailto:Cogl@lists.freedesktop.org">Cogl@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/cogl">http://lists.freedesktop.org/mailman/listinfo/cogl</a>