[Gegl-developer] Review of public GEGL API

[Øyvind Kolås]

On 12/4/06, Martin Nordholts <enselic at gmail.com> wrote:
> > perhaps gegl_node_connect_to (source_node, source_pad,
> > destination_node, destination_pad) or some other name could be used.
> Ah yes, you are right, it makes much more sense to pass 'self' first,
> instead of 'from to'. This aspect completely slipped my mind. A node
> class method for connecting must be in the public API.
>
> Wouldn't connect_from be a more logical name than connect_to? In code,
> you would write "the input pad of this (self) node should be connected
> *from* the output pad of the other (source) node'.

I still want the behavior you initially wanted, perhaps gegl_node_attach_to
is a good name for a class method with that behavior.

> If the syntactic sugar functions are kept, I don't think they should
> start with gegl_node_, since that implies that they are class methods
> and hence one expects that 'self' should be passed as the first argument.

This is not a problem, one creates a linked chain starting from "self"
and onwards.

> However, the need for these helper functions can indeed be questioned.
> For hard-coded demonstration programs they are useful, but I find it
> difficult to imagine when they would be useful in, say, the next GIMP.
> There you would have some algorithm that dynamically link nodes together
> based on the current structure of the layers and their blend modes etc
> in an image.

Most probably not dynamically, but keeping a graph in sync with the
other data structures. And encouraging such functions existence in
python|ruby etc variations of the bindings will make coding with GEGL
a bit more pleasant.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/