Review of public GEGL API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.   2. The term "bounding box" is clearer than "defined region". So
      *gegl_node_get_bounding_box      *
      would be better than
      gegl_node_get_defined_rect


- Martin Nordholts
> The host facing GEGL API is getting closer to a stage where it should> be scrutinized before an initial tarball release. The API that is> getting stable is the host facing API, which is the portions of the> GEGL library exposed in gegl.h[1]. Usage of this API is illustrated in> the hello world example[2] in the documentation.>> 1: http://cvs.gnome.org/viewcvs/gegl/gegl/gegl.h?view=markup> 2: http://cvs.gnome.org/viewcvs/gegl/docs/hello-world.c?view=markup>> Comments and requests for renaming/clarification of this API would be> most welcome, the API to write plug-ins as well as the XML> serialization format are still not ready to be stabilized. But the> public API should be possible to keep largely unchanged whilst adding> optimizations internally in the GEGL engine.>> Right now I think there is two issues that needs resolving, the most> important one is probably exposing introspection of meta> data/properties for operations. The> current function GSList * gegl_operation_list_operations (void); which> returns a static list of operation names is not good enough. To> discover the parameters a temporary GeglNode needs to be instantiated> and it's list of properties must be examined. I want to avoid exposing> the GObject internals of GEGL in the public API.>> The other issue is hit detection, this is a more minor issue, and I> think introducing API to do this can be postponed until later, but> most probably adding a function similar to the following would work:>> GeglNode *gegl_node_hit_test (GeglNode *node, gint x, gint y, gdouble> alpha_threshold);>> As part of exercising the API some additional GUI integration code has> also been written, most importantly GeglProjection a cache/queue for> rendered output from a node (which probably will be reused internally> in GEGL for caching) and GeglView a GtkWidget for viewing/requesting> renderings from a projection. GeglView together with some other> convenience code for using GEGL from GTK+ will probably be wrapped up> in a helper GUI library.>> /Øyvind K.>   
_______________________________________________Gegl-developer mailing listGegl-developer@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux