[Cogl] Cogl in Python

[Robert Bragg]

> I guess exposing it as gobject "interfaces" wouldn't be possible? (if that
> would have been the case my generator would have "mixed in" all the
> "interface" methods into the appropriate classes)

My understanding is that the gobject introspection scanner uses
runtime introspection to figure out when something is an interface or
not, it isn't something it gets from gtk-doc annotations. This
presumably relies on following the gobject naming conventions so the
scanner can find e.g. a cogl_offscreen_get_type() function that
returns a GType that the scanner can then see implements a
CoglFramebuffer interface and see what other classes it inherits from.

Although Cogl provides a couple of get_type() functions (so we can
have boxed-types for CoglMatrix and CoglHandle which are exposed via
properties in Clutter) those _get_type() functions intentionally are
in a cogl_gtype_ namespace because we think it's likely we would want
api like cogl_texture_get_type() for other purposes.

We are also limited to only describing boxed types this way because
CoglObject doesn't itself inherit from GTypeInstance and so runtime
introspection of CoglObject instances can't work currently.

>
> I have one line in the D crate example marked with XXX because of the cast:
>> >   fb = cast(cogl.Framebuffer*)onscreen; // XXX
> and now thanks to your email i know why it's needed, and also how i could
> fix it - thank you.
> Until now i have managed to avoid having *any* substantial modifications
> to the bindings - it all straight translations from the GI data, it would
> be good if things could stay that way, but if that's not possible i guess
> synthesizing the "interfaces" could be an option.

One thing to consider here is that however you would "synthesize" the
interfaces the bindings wouldn't be able to assume the cogl interfaces
are associated with GTypes at runtime which maybe they do currently. I
imagine this detail would be a problem for other existing g-i based
bindings so even if we could find tricks to generate .gir data
describing what we consider to be an interface the bindings would also
need a way to differentiate cogl objects at runtime.

>
> artur
>
> PS. I don't think i've ever used cogl.Material - if there exists some simple
> self-contained example that uses it i could try it from D using my bindings.
> But these parts of GI indeed look sane, so the problem may be elsewhere.

CoglMaterial is basically just the old name for CoglPipeline. One
thing that might be causing some confusion here is that the Cogl
library exposes two apis currently; the 1.x api that's used by Clutter
including the CoglMaterial api but can't be used to write standalone
applications and the experimental 2.0 api which is what standalone
examples such as cogl-crate use and in that api CoglMaterial is
replaced by CoglPipeline. When using the C api these are more clearly
separated because developers can only access the experimental 2.0 api
if they explicitly #define COGL_ENABLE_EXPERIMENTAL_2_0_API.

kind regards,
- Robert