I have struggled myself through autotooling, and in the process of
doing so structuring the codebase for my video editing project, there
are still some minor restructuring that should be done, but I think the
current arrangement is a good approximation of how things should be
split up.
toplevel (outside packages)
gggl - core to do image processing
image - directory where the frame storage, pixel-
formats etc. is defined
op - directory where the op structure is defined
ops_core - core operations used by gggl, like
providing new buffer, automatic pixelformat
conversion, internal tee, null sink
gggl-ops-base - a base of core processing ops for gggl,
contains no external dependencies, but png
loading/saving could probably be added
to this package, to have some file IO
gggl-ops-extra - this is where I've put all ops that either
have external dependencies (typically sources
or sinks), and ops that are pure toys
oxide - compositing and animation abstraction on top of gggl,
that uses a tree based data model, that allows clones,
sequences, clips etc. (this is the xcf2 playground)
bauxite - gtk-tree-model reflecting the oxide data structure,
which is the engine behind the gimp's layers dialog
"on steroids" ui, slate for rewriting using roxide
rgggl - ruby binding to gggl, should be possible to rewrap
almost the exact same binding to gegl later, this
this binding provides a mapping turning the integer
handle based api of gggl into classes.
roxide - still not mature ruby binding to oxide very much
a work in progress
tarballs reside at http://pippin.gimp.org/snapshot/ after this
autotooling it should be easier for other people to experiment a little
with the concepts I've been developing the last year.
/pippin
