On 16/01/04, Øyvind Kolås wrote: > We need to sort out our Terminology, this will facilitate both > communication internal to the project, and the projects communication > with other projects, for instance the Gimp. I agree with this. It's easy to get confused with the terms. Current code uses : Node: Class that governs nodes and connections between nodes. About the highest level thing with connections. (pretty partial to this) Property: Inputs or outputs of nodes. The "pads" inside the Nodes you make the connections between. (I like properties a little more than attributes, feels less formal and I tend to view them as close kins of gobject properties. And would like to use GParamSpecs to specify them too) Connections: Lines that connect properties to properties Each line in your graph below is between specific input and output property of a node. Filter: Something with an evaluate method (Ive been using this one to describe "atomic" operations, not ones that are whole graphs put together and used as one operation) (Im not really partial to this, it might be called an op too) Graph: Collection of filter nodes. (not really that partial to this either) So I have in the code right now... Node / \ Graph Filter as the composite/container and atomic pattern right now. > The Graph, (data flow downwards,. wheter data flows down or up is something > we should decide on as well, I like downwards flow, but that's just a matter > of personal preference) No preference on flow direction > > .-----------. > | |<------- source node > |membuf | > | ,---.<----------- output port > `---' | `---' > .--^--. > / \<--------- connection > | .---. | .---. > | | `---'<------ input port > | |coloradj | > | | .---. |<-- filter node > | `---'/ `---' > | / > | / > .-. | .-. / .-. > | `---' `---' |<-------- composer node > | sidebyside | > | .---. | > `----' | `----' > | > .---. | .---. > | `---' |<--------- target node > |display | > | | > `-----------' > > (type of node not shown, decomposer,. e.g. RGB->R,G,B and similar) > > At least the following concepts are important that we use consistantly, > preferablly using the least ambiguous, of the terms listed for eact, and > not use the others. > > Composer Node > A type of node that has more than one input,. compositing > nodes,. adding of alphamask,. and similar Composer Node is nice I think. > Connection/Edge > From a programmer and informatics point of view, a graph has > edges, but a end user might just as well want to call them > Connections, should there be any policy on this? I vote for connections. > Decomposer Node > A type of node that has more than one output port. Decomposer. > Filter/Op > These two should only be used about node's that have both inputs > and outputs, and thus transform image data. Using them for any > other nodes is just plain confusing. Actually I find the concept > of Op's confusing, and would prefer that a filter is a node that > has exactly one input, and exactly one output,. thinking of for > instance brightness/contrast, for me at least thinking is easier > using the term Filter. Id go for ImageFilter or ImageOp if it has exactly one image input and output. > Graph > A compositing graph consisting of Node's, (and Graphs (which > have an interface in common with Node's?)) Yes. Cool > Node > An instance of a kind of operation that is performed by gegl, > anything processing image data,. wheter creating it, > transforming it or consuming it. I prefer that it doesnt imply it processes image data. > Parameter/Attribute > Some value that can be changed for a node, can be the amount of > contrast in a color adjustment filter, the file to load from a > png file, position of a layer etc. It is possible to generalise > parameters and ports into a attribute list where attributes have > read/write flags, meaning even parameters could be changed by > the filter, if this is done attribute is a more appropriate > word. Yes. I would want to call that attribute list the input and output properties of the node(so I vote for property on this one). Id call attributes that get added in this way you are talking about dynamic properties. > Port/Pad/Source/Input/Output/Faucet/Sink > Exists both in input and output variety, the place where > Connections are made between the Nodes. Properties. Id call them input and output properties of the nodes. > Source-, Provider-, Leaf Node > At the moment called, GeglNoInput, GeglProvider is probably a > better name, any node that provides provides image data only > from parameters, e.g. png load, v4l frame grabber, noise gen, There is no more GeglNoInput. That was the worse name I ever thought of. Anything but that.. Please. Leaf is fine. FileIn and FileOut describes the file versions of these nicely. > in memory framebuffer etc. > Target-, Root-, Consumer Node > A node that has a single input port, and no output ports. > Example, file writers, display, statistical analysis, (assuming > that we're only passing image data). Use a descriptive name for what it actually does maybe... like FileOut > Comments and changes are expected, but at least this could be a starting > point. If things need to change names in the code that is no problem > yet, but once other projects starts depending on gegl, variable, object, > filename, and other changes get a lot harder. What about if I have to change them. Anyway I might be presuaded... lord knows I changed the names so many times already Ive used every one for every single thing at one time or another. I think Generally I only feel strongly about the few names up at the top of the library like Node, input output Properties, Connection, everything else I am not that keen to invent further bad names like "GeglNoInput". I will never live that down I know... Calvin
