* Colin Bennett <trigonododecahedron@xxxxxxxxxxx> [040903 21:44]: > ... I've spent some time since I first started looking at GEGL trying to > understand the GObject system, since I've never used it before, and have come > to the sad conclusion that it is N.A.S.T.Y. I reached the same conclusion, which was also what lead me to implementing a gegl like library in plain c, the number of entry points I've ended up with into that library is very small, there are still loose ends, and things not implemented since my original goal was to do a global %s/gggl/gegl/ on all my source files. A lot of work has gone into GEGL, and the code base has features not present in gggl. But gggl has one main feature which is the feature I demand when developing, it actually does something. It has been briefly been discussed whether GGGL could be used instead of GEGL for gimp integration, the system that GGGL is a part of is already experimenting with effect layers, layers groups, clone layers and other benefits that GEGL will bring gimp, the file format used by the library above GEGL is also the xml based catalog format I am proposing for a future gimp file format. http://freedesktop.org/~pippin/aluminium/ What benefits would we gain from using gobject within GEGL? Given that the api needed to interact with GEGL is very small. ref. http://freedesktop.org/~pippin/aluminium/aluminium-0.0.150/gggl/gggl.h An intial plan was to start porting my hosting application gradually to GEGL by changing the core image buffer representation in GGGL with the new cache system Daniel has been implementing. /pippin -- .^. /V\ Øyvind Kolås, Gjøvik University College, Norway /(_)\ <oeyvindk@xxxxxx> // <pippin@xxxxxxxxxxxxxxx> ^ ^
