[Gegl-developer] terminology / naming conventions

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

 



Right now I'm trying to harmonize the gggl terminology towards the
glossary I create a while ago, (that glossary now resides at
http://pippin.gimp.org/gggl/glossary.html , in the processes of search
and replace within gggl I have also turned to the GEGL sources to see
whether the naming conventions hold there as well.

I have changed (almost) all occurrences of "node" in the gggl source with op (short for operation), this because the term node is very graph
centric, and does not convey the notion that it has the capability to
process something. It is possible to say a graph of operations linked by connections. It is easier to have a smaller vocabulary, and the term
Op(eration) also work better on higher abstraction levels. Thus I think
this is a search and replace that would work within the GEGL code base
as well.

GEGL uses the term source/sink for the end points of connections, I think this is a bad term to use because the relation ships flips when
you look at the model on different levels.

A simple graph that could be present in a web cam app illustrates this:

.-----.
| v4l | <- source op
`-----'
  | <- source
  |
  | <- connection                   |
  |                                 |image flow
  | <- sink                         |
.-----------.                     \  |  /
| bcontrast |  <- filter op        \ | /
`-----------'                       \|/
  | <- source
  |
  | <- connection
  |
  | <- sink
.----------.
| png_save | <- sink op
`----------'

At the API level there are no inconsitencies, but from the plug-in / operation programmers point of view, things start to get mixed up.

          | |
          | |                       |
          | | <- sink               |
.----------------------------.       |
|                            |       |  image flow
|                            |       |
| bcontrast                  |       |
|                            |    \  |  /
|                            |     \ | /
`----------------------------'      \|/
          | | <- source
          | |
          | |


the processing within the bcontrast op would read data from the sink
side of the connection, and provide data on the source, this can be
explained with the notion that when bcontrast fetches it's image data
it _is_ a sink op, and it also acts as a source op when it provides data.

I am not quite sure what is meant by sinks / sources in gegl-node.h
because of this, I'd advocate keeping the sink/source terminology in
gegl-connection.h but rename sinks/sources within the operations to be
called input_pads and output_pads. Thus one would be connecting the
source and sink ends of a connection to input and output pads of
operations.

Connections could be renamed pipes to give an even better indication of
the flow, but source/sink of a connection conveys it quite well already.

The act I call processing is called evaluating in GEGL, I feel this is an issue where I probably have a stronger bias towards the terminology
I have been using, both terms probably have merit, and I'll leave the
term process in gggl for the time being.

/pippin


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

  Powered by Linux