Hello,

I too am interested in a gegl-sharp library in particular for F-Spot.

I've used GAPI to create a set of managed bindings for GEGL. I've run into a few problems trying to convert GEGL's hello-world.c into my own gegl-sharp hello-world.cs.

1. gegl_graph_new returns a GeglNode. While this is plausible in C through the magic of casting, it creates a circular dependency in C#. The metaphor GAPI creates for us is: "A Node is a Graph. While a Graph is a Node."

2. There are lots of instances of va_list usage in the API. Examples are the gegl_node_set/get functions.

I'm not very familiar with the GEGL source so I was wondering if there are any suggestions on how we could get the ball rolling to make GEGL binding friendly?

However the good news is that the bindings compile and I'm able to get the unmanaged code to execute within Mono and instantiate various objects.

george

I think it makes perfect sense for GeglGraph to be moved into or possibly subclassed from GeglNode. The concepts are similar enough to warrant such a change.

In response to Samee's post, I don't care much for a stabilized API at this point. The C# bindings are automatically generated by GAPI. The bindings thunk down into native code so it's not like I'm re-writing GEGL in C#. However if a new library is released then the .so version is bumped and it doesn't really affect my bindings at all.

In the worst case I can always statically link for the short term.

george

On Sun, 2006-29-10 at 02:37 +0200, Øyvind Kolås wrote:

On 10/28/06, George Talusan wrote:

Hello,

I too am interested in a gegl-sharp library in particular for F-Spot.

I've used GAPI to create a set of managed bindings for GEGL. I've run into a few problems trying to convert GEGL's hello-world.c into my own gegl-sharp hello-world.cs.

1. gegl_graph_new returns a GeglNode. While this is plausible in C through the magic of casting, it creates a circular dependency in C#. The metaphor GAPI creates for us is: "A Node is a Graph. While a Graph is a Node."

The reason I changed gegl_graph_new to return a GeglNode instead of a graph was to avoid casting in C. It might even make sense to move all of the code in the GeglGraph super class into the GeglNode subclass to avoid the issue completely (I already dislike the large amount of code needed in the GeglNode class though.)

2. There are lots of instances of va_list usage in the API. Examples are the gegl_node_set/get functions.

I'm not very familiar with the GEGL source so I was wondering if there are any suggestions on how we could get the ball rolling to make GEGL binding friendly?

It shouldn't be harder to bind GEGL than to bind gobject itself. Like gobject gegl also provides functions to set/get individual properties:

void gegl_node_set_property (GeglNode *object, const gchar *property_name, const GValue *value); void gegl_node_get_property (GeglNode *object, const gchar *property_name, GValue *value);

I presume this should be sufficient.

/Øyvind K.

Hi Gabriel,

I haven't used Gapi before either but these errors were easy to fix. I'm keeping an eye on the public API and will give it another shot once things start to stabilize.

The major problem I had was with the Gapi-generated factory method for creating a node from a graph would have the is_graph property set for the node. Confusing.

george

On Fri, 2007-01-26 at 23:16 -0600, Gabriel Burt wrote:

On 10/28/06, George Talusan wrote:

I too am interested in a gegl-sharp library in particular for F-Spot.

I've used GAPI to create a set of managed bindings for GEGL. I've run into a few problems trying to convert GEGL's hello-world.c into my own gegl-sharp hello-world.cs.

Hi George, sorry for not replying earlier. Have you done any more work with this? I also had trouble getting the helloworld example to work - I could get some output, but not the correct output.

I have never used Gapi for binding before. You had to do some fixups to get around these types of errors

generated/Node.cs(411,20): error CS0102: The type `Gegl.Node' already contains a definition for `DependsOn' generated/PadType.cs(14,17): error CS0103: The name `G_PARAM_USER_SHIFT' does not exist

right? We should collaborate to get the mono bindings working.

Gabriel