* David Neary <dneary@xxxxxxx> [040111 03:51]: > Hi, > > I hope people don't think it's out of place for me to make this > suggestion. If so, I guess ye'll just ignore it anyway... > > I think it might be useful for gegl, as well as for the GIMP, to > have a clear roadmap of things that absolutely, positively must > get done before the GIMP can use gegl. I don't really know what > those things are, but I imagine that finishing GeglImage is one, > although that goal is probably too vague to be a proper > milestone. > > It would be interesting to have a number of measurable > milestones, and to start releasing gegl pretty soon. I suppose > that one of the things that will be needed when releases start > will be documentation on the philosophy and usage of the library. > > What do ye think? Do ye feel that gegl is small enough not to > have any releases until it's actually at a stage where twe can > use it? In any case, measuring what's required before we can use > it is, I think, worthwhile. I have been continuing development of libgggl, my simplified gegl like library, and the application I use libgggl in, bauxite, (my goal is to ditch libgggl, and use gegl instead). There are some things in my libgggl api that will change, to accomodate my change to gegl, (or the adoption of some of the codebase into a gegl testing application.) I think an approach where you first have a standalone graph/node editor, where you connect things, adjust parameters, etc. similar to what bauxite is, is a better and smaller target for initial testing. It would also be benficial for developers developing GEGL op's, since you could have a lightweight testbed. http://schweden.mine.nu/bauxite/screenshots/bauxite_0_67.png is a screenshot from this night, when I managed to get my simplistic v4l framegrammer input node working. The main part to recirculate is probably the graph widget, which isn't finished, it has some performance issues (mainly due to cairo and related libraries are not optimized yet), and the graph layout needs to be reworked,. the graph layout code is seperated from rendering and interaction,. and since it is in a semi working manner now, I have paused that part of development and focus on other issues. One of the next things I'll be looking into for bauxite is a composite fileformat,. at the moment I just use xml files, that are not bundled with the actual image data, I am not sure if some kind of VFS should be implemented,. I envision the ability to treat normal paths and paths where a tarball is a directory just the same. No compression of the tarball, since I assume image data to be compressed in a image data specific manner. Versioning can be added to the files,. making it possible to incrementally save new versions,. and do a cleanup to remove unused data from an archive. At least this is the kind of roadmap I would envision could make sense,. incrementally building up complexity. /Øyvind K. -- .^. /V\ Øyvind Kolås, Gjøvik University College, Norway /(_)\ <oeyvindk@xxxxxx>,<pippin@xxxxxxxxxxxxxxxxxxxxx> ^ ^
