> On 12/4/06, Martin Nordholts <enselic@xxxxxxxxx> 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.
gegl_node_connect_to is much better. Why would we want to have two terms
for the same thing? The code for it would be
gboolean
gegl_node_connect_to (GeglNode *self, const gchar *source_pad_name,
GeglNode *sink, const gchar *sink_pad_name)
{
return gegl_node_connect_from (sink, sink_pad_name, self,
source_pad_name);
}
>
>> 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.
Ah yes, silly me.
>
>> 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.
Ah yes, good point.
- Martin N.
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
