On 1/26/07, Håkon <haakhi@xxxxxxxxx> wrote:
> Right, some questions. I'm not familiar with the code, sorry for asking
> about anything obvious.
>
> What does one node being a child of another do? Why wouldn't you just create
> all your nodes at top level and connect them? Can you only connect siblings?
> Does a top level node have an operation?
A node that is a child of another node will be destructed when the
parent is destructed. This is similar to how memory management works
in a GUI toolkit with containers, destroying the container destroys
the child nodes as well. I also want
to add the ability to unref a child node directly which would break
the parent/child relationship.
There is nothing that stops you from connecting non-sibling nodes, the
parent/child relationships are mostly there to organize code/data
structures in a manageable way.
> gegl_node_connect_from and gegl_node_connect_to seem to work opposite from
> what I'd expect.
> Having two operations that do the same thing but with different argument
> order is usually bad. If they aren't unambiguously named it certainly isn't
> going to improve readability, which seems
> to be the intention.
Both of the methods work on a node, thus for connect_from you connect an
inputs pad of a node from the output pad of the other node. And opposite, the
first argument to the method is "self", the object being acted upon.
connect_from
is the one that is used internally and makes most sense from an OOP
point of view.
But when writing code it is perhaps more natural to think that one
wants to connect data from an output pad of a node to the input pad of
another node, hence gegl_node_connect_to exist in the public API to
allow writing code that reads
more naturally.
> From what I understand one output can be connected to several input. Can one
> input also read from several outputs, or does a connect_to to an occupied
> input disconnect the previously connected output? If so, is there any way
> for a node take an arbitrary number of inputs?
A named input pad for instance "input" can only read from a single
source, composer nodes like "over" or "difference" also have an input
pad named "aux"
which other data can be connected to.
> gogl_node_detect seems to have somewhat limited use... I see how it would
> work for a simple concatenation of images or non-transparent overlays, but
> what should it return if several inputs are merged?
At some point it will probably be extended with options to specify
whether the current mode of operations should be used, or if it should
have pass the request through transparent regions of the overlays.
> What are proxies used for? "Route between nodes of a subgraph contained
> within a node"? Isn't that what normal connections do?
Proxies are used when creating a node that is a graph. This allows you to create
a sub graph that can be reused as a node in another graph:
The following ASCII art illustrates an example, here we load an image, and have
inserted a node that applies a watermark (it could be more complex than this).
The sub graph is a node that has two normal children and two proxies, one for
each pads, the proxies are siblings of the other children of the graph and thus
can be connected. These proxies act as middle men making it possible to use
the watermark node directly in the top-level graph.
.----------.
| png-save |
`----------'
|
.--[output]----. <- watermark node/graph
| | |
|.------------.|
||proxy-output||
|`------------'|
| | |
|.-----. |
||over | |
|`-----' |
| |\ |
| | \ |
| | \ |
| | .-----. |
| | |load | |
| | `-----' |
| | |
|.-----------. |
||proxy-input| |
|`-----------' |
| | |
`--[input]-----'
|
.--------.
| load |
`--------'
In code: (not tested)
GeglNode *gegl = gegl_node_new ();
GeglNode *load = gegl_node_new_child (gegl, "operation", "load",
"path", "image.png", NULL);
GeglNode *png_save = gegl_node_new_child (gegl, "operation",
"png-save", "path", "output.png");
GeglNode *watermark = gegl_node_new_child (gegl, NULL)
GeglNode *in_proxy = gegl_node_get_input_proxy (watermark, "input");
GeglNode *out_proxy = gegl_node_get_output_proxy (watermark, "output");
GeglNode *over = gegl_node_new_child (watermark, "operation", "over", NULL);
GeglNode *overlay = gegl_node_new_child (watermark, "operation",
"load", "overlay.png", NULL);
gegl_node_connect_to (over, "aux", overlay, "output");
gegl_node_link_many (in_proxy, over, out_proxy, NULL);
gegl_node_link_many (load, watermark, png_save, NULL);
gegl_node_process (png_save);
g_object_unref (gegl);
The operations in the meta category are implemented using this internally,
operations that are graphs themselves http://gegl.org/operations.html#cat_meta
--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
