Tino Schwarze wrote: > I recommend looking into David Hodson's Gimpeon at > http://www.ozemail.com.au/~hodsond/gimpeon.html > he's already figured out how to abstract such a system and I guess we > could get at least some nice ideas from his work. Just remember that Gimpeon is intended for automatically processing sequences of images, rather than working on a single image. (It's also very much a work in progress, nowhere near a finished product!) It uses some of the ideas suggested for 2.0, but they're in a slightly different context. (And it's written in C++, which I know some of you won't like - but when I drop back to straight C to work on the Gimp, it's sooooooo frustrating!) Just to expand a little - Gimpeon is based on film effects work, where the workflow (using the tools I'm most familiar with) is something like this: * get the source image sequences, and make reduced resolution versions of them. (You generally can't work efficiently at full resolution.) * set up the basic processing sequence. This is usually done at low resolution, looking at one frame, but also involves stepping through the sequence (to check animated efects) and switching to full resolution (to check fine detail). * once everything is set, automatically generate the full sequence at low resolution. If this looks OK, generate the full sequence at high resolution. * wait for the effects director to tell you to do it again. (Hah!) Gimpeon appears to use "boxes and lines" as its main UI component, but I'm actually planning to provide a better interface on top of that. The user will always be able to directly edit the processing graph, but they will generate it in the first place by applying filters to images - the graph gets built behind the scenes, much like it would be (perhaps) in the Gimp. Just as an aside - one of the main annoyances I have with GTK is that manually setting a widget value triggers it. This makes doing a clean Model/View/Controller design very messy! -- David Hodson -- hodsond@xxxxxxxxxxxxxx -- this night wounds time
