This is similar to the exsisting setup, but makes use of the cleaner
(I think anyway) interfaces defined above.
-GeglNode-
*GeglGraph*
-GeglImageSource- Implements <GeglImageProducer>
-GeglReadImageFile-
*GeglReadPNG*
-GeglReadImageSequence-
*GeglReadMpeg*
*GeglSingleColorImage*
*GeglPatternedImage*
-GeglImageSink- Implements <GeglImageConsumer>
*GeglXViewer*
-GeglWriteImage-
*GeglWritePNG*
-GeglWriteImageSequence-
*GeglWriteMpeg*
-GeglPipe-
*GeglPrint*
-GeglFilter- Implements <GeglImageProducer> and <GeglImageConsumer>
-GeglPointOp-
-GeglUnary-
-GeglBinary-
-GeglComp-
*GeglConvolve*
*GeglBlur*
But you need something abstract above ImageSource, ImageSink, and
Filter, since you will have Ops that have nothing to do with images,
and they
will still have process, inputs and outputs, just they arent image
inputs or outputs necessarily, etc.
Ah, ok. Then I'll stick a GeglImageOp in the approiate place above.
hmm, I made a mistake here. The point of having a <GeglImageConsumer>
and <GeglImageProducer> interface was that you didn't need ImageOp.
Implementing the interface is enough to show that is has image inputs
and/or outputs. I didn't like the ImageOp abstraction. ImageOp said
nothing about whether it had inputs, or output or both. Futher, what
happens when you have nodes that have two different kinds of inputs or
ouputs? Does it really belong under ImageOp, or, for example, should it
be under ScalarOp? You can't have it both ways unless one of them is an
interface.
I didn't make it explict at the time, but really the Consumer/producer
interface should be something like:
<GeglDataConsumer>
<GeglImageConsumer>
<GeglScalarConsumer>
<GeglPixelConsumer>
and a similar hierarchy for <GeglDataProducer>. This allows objects to
be a little more flexible in their organization.
--
Dan
