Tino Schwarze wrote:
> I recommend looking into David Hodson's Gimpeon at
> 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
* 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
* 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 -- [EMAIL PROTECTED] -- this night wounds time