Øyvind Kolås skrev: > On 12/2/06, Martin Nordholts <enselic@xxxxxxxxx> wrote: >> After going through gegl.h and hello-world.c, these are my opinions. >> >> 1. The order of the parameters to gegl_node_connect should be >> reversed, that is, it should be >> >> gboolean *gegl_node_connect* (GeglNode *source, >> *const* gchar >> *output_pad_name, >> GeglNode *sink, >> *const* gchar >> *input_pad_name); >> >> This is the order used in gegl_node_link, and personally I prefer >> to write 'from to' rather than 'to from'. In any case, the order >> of the parameters should be the same throughout the API. > > I agree that all of them should behave the same. The gegl_node_link > (_many) functions are syntactic sugar on top > of this one, and should maybe be removed. > > Maybe the verb should be changed as well, the rationale for the > current name is that you connect to the input pad of the object being > modified (and it feels natural that the first object is the one being > modified.) > > 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'. 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. 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. > >> 2. The term "bounding box" is clearer than "defined region". So >> >> gegl_node_get_bounding_box >> > > I also agree that this needs changing, and the suggested name is a lot > better than the current one. > > The names of the concept internally, and a decision externally > might be propagated to the inside as well. Another option might be > gegl_node_get_bounds , or with a naming choice more similar to the > ones used by cairo, gegl_node_get_extents. > > /Øyvind K. I think _get_extents is a feasible alternative to _get_defined_region, but I prefer 'bounding box', probably because that is the term I am more familiar with. - Martin Nordholts _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
