Cairo
<jdahlin> owen, shouldn't be too hard to create a gir for cairo
<owen> jdahlin: can you make it match http://www.cairographics.org/manual/language-bindings.html ? I doubt it
<jdahlin> owen, that would have to be annotated somehow
<owen> jdahlin: you should be able to call cr.get_target(), get a surface, and then call methods specific to *that subtype* of cairo_surface_t
<jdahlin> to map cairo_t to Cairo.Context
<jdahlin> hmm, I'm not too closely familiar with these subtypes, let me see the headers
<owen> You have to know that surface/font/pattern have get_type() functions and know how to map the results of that to subtypes
<owen> Probably better to just figure out how you do the integration between gobject introspection and a hand written binding so that you can pass the wrapped types back and forth
<jdahlin> right, cairo seems rather tricky to get right
<owen> jdahlin: It's certainly far from unique in that, though it's more heavily OO than many old style C libraries
<jdahlin> owen, I a gir could be written manually although
<owen> jdahlin: There seem to be some need to be able to "claim a type" ... for something to register itself (in JGir or pybank) as "I am the handler for cairo_surface_t, call me to create a proxy object
<owen> jdahlin: You think so?
<jdahlin> which would make it far easier to get the class hierarchy
<jdahlin> owen, for pybank I intend to integrate it with pygobject
<jdahlin> which is going to be plenty of fun
<jdahlin> yes, it doesn't seem to difficult, at least not the surface subtype problem, but there might be others
<owen> jdahlin: The point I was trying to make is that class heirarchy is not just cairo_pattern_create_linear => CairoLinearGradient
<owen> it's cairo_surfafce_get_source() => a surface subtype that needs to be determined by RTTI
<owen> (and by RTTI I mean cairo_surface_get_type())
<jdahlin> hmm, true
<jdahlin> that would need to be done in the bindings themselves, the gir won't be able to express that
<jdahlin> but creating the right class hierarchy and putting the methods in the right class with the right name should be doable although
<jdahlin> which would get you half-way
<owen> jdahlin: Is half-way useful?
<jdahlin> owen, definitely less useful than integrating with existing libraries
<jdahlin> owen, jgir should really try to integrate with java-gnome at some level
<owen> jdahlin: half-way is useful with pygtk defs, because you have the overrides, but half-a-dynamic binding is half a dynamic binding
<owen> it's basiclaly the gtk_widget_get_parent() problem, except that you can't retrieve the GType from a cairo_surface_t
<walters> right now i am mapping cario stuff to com.sun.jna.Pointer
<owen> among other things
<walters> so as long as the cairo binding could construct stuff from Pointer we could get away without the hand written bindings having to know about jgi
<owen> (cairo_surface_new_from_png_stream() is way messy)
<owen> walters: I don't think that's a complete solution .. JGir has to be set up so that you can *seamlessly* pass types back and forth between hand rolled and native bindings
<owen> I think internally JGir has to know "the proxy boxed type has to be constructed in this particular way" .. so you need a way to register that with JGir
<walters> so this registration would have to be known at jgir-compile-all tie
*time
the simple solution is to have jgir depend on the cairo bindings
<owen> walters: Donj't the jgir-compile-all jars just delegate to the the base Jgir machiner for boxed proxy construction?
<walters> the harder one would be some sort of plugin system
owen: but i need to write out what class the argument is
<owen> mm, but you are right, if you hae a method that returns a Cairo.Context, you need Cairo.Context on the class path when comiling
<jdahlin> walters, yes, that patch looks good
<jdahlin> owen, a gir is useful outside of language bindings though
owen, there's just this tiny piece missing to make the cairo api wrappable
<owen> walters: cairo is certainly a bit of special case ... there aren't Java bindings we care about for FreeType/Xlib/tec.
<walters> right
<jdahlin> owen, which would be special handling of cairo_surface_t
<owen> Hmm, I wonder if we could actually make the typelib responsible for registering the cairo types
(in regards to the discussion we had yesterday)
So, basicaly, when gobject-introspection loads a special typelib, it knows to go ahead and call g_type_register_boxed()
jdahlin: You still have another problem - though- what do you map the cairo types with inheritance to?
<jdahlin> owen, for pybank I wanted to reduce the amount of functions called when importing a module
<owen> GBoxed is not deep_derivable
<jdahlin> owen, I don't really see any problems
<owen> jdahlin: registering GTypes when importing a module doesn't seem like an issue to me... it's far less extreme than importing gtk initializing gtk
<jdahlin> more than it would probably not be a GBoxed
perhaps a GstMiniObject like fundamental
<owen> jdahlin: Does the GIR format support objects that are not GObjects?
jdahlin: (not GObject registered)
<jdahlin> owen, yes
owen, the gir is generic, you can express, say a python api in it
<walters> well, it supports structures; we could add an annotation like "this function is the ref/unref"
<owen> jdahlin: with inheritance?
<jdahlin> owen, yeah
not multiple inheritance though
<owen> not needed for cairo
<walters> well the GIR is only half the story
<jdahlin> not sure if the typelib support it though
<walters> the typelib/bindings aren't really targeted for non-GObject
<jdahlin> but that could be extended
maybe just setting the GType to 0
<owen> I still don't see how you would handle cairo_surface_get_type(), at least without egregious extension of the typelib/gir format
<jdahlin> owen, I'm thinking more in terms of letting the binding itself sort that out
if a cairo_surface_t is returned, _get_type() needs to be called to find out which kind of surface it really is
<owen> jdahlin: Still not convinced of the value of half a typelib :-)
<walters> so it sounds like we are coming back to integrating with custom bindings
