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