Re: [Gegl-developer] RFC: Including operation source code as op class metadata

[Jon Nordby]

Merged, since there were no objections.
Can now get the source code of majority of components provided by GEGL
(primary exception is the generated ones) using:

  const gchar *source = gegl_operation_get_key(opname, source);


On 11 January 2015 at 17:55, Jon Nordby jono...@gmail.com wrote:

 In some development environments using GEGL, like imgflo+Flowhub it is
 useful to be able to see the source code of an operation in used. Both to
 understand how existing operations work and as a basis when writing new
 ops*.

 The following branch allows operations to include their source code as
 operation class metadata (using the source key) by using GEGL_OP_C_SOURCE
 instead of GEGL_OP_C_FILE in their op. The app can then query and display
 this like any other metadata.
 https://git.gnome.org/browse/gegl/log/?h=operation-source

 If there are no objections I'd like to merge this some time next week.
 - Jon

 * As mentioned to pippin at 31c3 I've found a way to basically implement
 live-code operations. Compile new/changed operation code as a .so file,
 using a unique suffix on the operation name, and then trigger
 gegl_load_module_directory()
 This will leak/keep the old operation class data, but this is small
 amounts of data for even long-ish development sessions compared to the
 images being processed.

 https://github.com/jonnor/imgflo-server/blob/master/components/example.c
 https://github.com/jonnor/imgflo/blob/master/lib/library.c#L357


 --
 Jon Nordby - www.jonnor.com




-- 
Jon Nordby - www.jonnor.com
___
gegl-developer-list mailing list
List address:gegl-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list

Re: [Gegl-developer] Support for loading meta-operations from .json now in master

[Joao S. O. Bueno]

Yay!  :-)

On 20 January 2015 at 15:08, Jon Nordby jono...@gmail.com wrote:
 Hi,

 a long standing enhancement[1] in GEGL has been to allow loading
 meta-operations from a serializable file instead of requiring them to be
 coded in C.
 At 31c3 I started working on this, and yesterday it reached a generally
 working state. Today I merged the code to master[2].

 Each .json file of right format that is found in the module path for GEGL
 will create a new GeglOperationMeta subclass. It will be register it with
 the specified operation name, and exported properties/pads.
 When the operation is instantiated, it builds up the subgraph of GeglNodes
 specified and connects. Property changes on the meta-operation are forwarded
 onto the real node inside.

 An example of the .json format can be seen here:
 https://git.gnome.org/browse/gegl/tree/operations/json/grey2.json
 This is a format also used by other dataflow/flow-based-programming
 tools[3].

 This for instance allows one to use the node-based editor Flowhub+imgflo to
 build a new image filter, save it as .json and then use it in GIMP[4]
 (screenshot). One can of course also hand-write the json files, or implement
 other editors for these.
 It might make sense to also implement serialization of a graph/sub-graph to
 this format directly in GEGL itself.

 Note: This adds json-glib 1.0 as a dependency of GEGL, so make sure you have
 it installed (including development headers).

 References
 1. https://bugzilla.gnome.org/show_bug.cgi?id=465743
 2.
 https://git.gnome.org/browse/gegl/commit/?id=564f45bad76eb0f888e628ea70345912dd68cbbb
 3. http://noflojs.org/documentation/json
 4. https://twitter.com/jononor/status/557570481206099969

 --
 Jon Nordby - www.jonnor.com

 ___
 gegl-developer-list mailing list
 List address:gegl-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list


___
gegl-developer-list mailing list
List address:gegl-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list