Hi Gary,

On Sat, Dec 23, 2000 at 02:45:42PM -0500, Garry R. Osgood wrote:
> >  > How would the "pupus" functionality be directly exposed to users?  The
> >  > answer is that it most assuredly WOULD NOT.  I do not advocate, in fact
> >  > I ABHOR the idea that the user should end up drawing a little tree
> >  > of boxes connected with wires.  That's your view as a programmer
> >  I want it! Hey, this is interactive Script-Fu!
> 
> I agree with Adam. It so happens that the directed graph
> abstraction which is serving his thinking about scheduling
> visually coincides with a user interface presentation where
> upstream branches of layers composite into common result
> sets. This happens to be two places where the abstract tree data
> type has taken root in the fecund (if imaginary) soil of Gimp
> 2.0. Trees happen to furnish a nice framework to think about the
> shape of a great many tasks, so this coincidence is common (and
> an ongoing source of confusion).
I thought about that tree thing a bit more. We should not opt for trees
but for directed graphs only.

We are only a very small step away from a visual programming language.
For example, a "choice box" would be almost trivial to implement. It
lets you chose/route your image(?) data another path "down" the graph.
So one could try several variants and subvariants. Such graphs could
even be constructed on-tye-fly while working with the GUI (though they
would get mazy very fast).

> If we dedicate the Gimp 2.0 core to nothing other than staging
> (various kinds of) compositing of result sets from different
> kinds sources (ideally, not all bit maps), then the user interface
> simply falls away from view. 
I agree with that.

> 2. Some (cache-boxes) are capable of persisting "upstream"
>    image presentation for "downstream" black boxes. Some other
>    component of the application might choose to associate with
>    such cache-boxes the notion of "layer", but that is the business
>    of that more or less external (and, me thinks, user-interface
>    housed) component. To the step manager, it is a step that
>    persists (parts of) images.
The caching issue is very important. A seprerate bunch of code with a
default caching strategy would probably be useful.

> 3. Some black boxes (it seems to me) house genetically engineered goats (large ones)
>    that pixel process. As an aside, These GEGL boxes are (hopefully)
>    the only interior places where some sort of physical
>    implementation of pixels matter -- how many bits they have, how
>    those bits relate to color and transparency components, what sort
>    of pixel and pixel area operations are capable of mapping a
>    region in one cache-box to a region in another. To pupus (the
>    step manager) it is just a surface -- it is neither capable of,
>    no interested in, the manipulation of the surface 'fabric.'
Ideally, the step manager is a stand-alone library which can be used by
other applications as well (think: a synthesizer like app using
independent sound processing boxes for sequencer, 303, filters etc.).

> So what is Gimp 2.0 -- the application -- do? Refreshingly (I
> think) not much. It configures a step manager of a particular
> arrangement that makes sense for the profile of requirements that
> some sort of user interface presents, authenticates that the
> version of user interface is capable of talking with the version
> of step manager present, (mumble, mumble, other kinds of
> sanity/compatibility checks) then steps back and lets the
> ensemble articulate. 
[...]

> It is this view
> that makes Gimp 2.0 largely a collection of shared object code,
> each shared object being a thing that a (likely) small group of
> individuals can dedicate themselves to and get to know
> particularly well, and there will be less of a need for someone
> to be knowledgeable about the Whole Massive Thing (as in Gimp
> 1.x) (the shared object may even be general enough to export
> to some other application, unchanged).
Let's talk about distributed objects! Using this framework, it would be
easy to implement a transport mechanism via some high-speed network and
interconnect several computers to do heavy scientific/industrial image
processing. The "pipelines" connecting the black boxes should be
pluggable.

> What concerns me is this style of thinking places a great deal of
> importance on coordinating interfaces and internal protocols; this
> is not a topic upon which UI, scheduling, image-processing, and
> specialty black-box architects (a kind of Gimp 2.0 third party
> contributor) should drift too far apart, reinventing wheels that are
> rolling in other parts. 

> The Monolithic Gimp of 1.x
> fame, being monolithic, permitted some laxity in the design of internal
> interfaces; distributing the application over autonomous processes
> require a little more formality in coordination.
I think we should set great store by software engineering in GIMP 2.0!
Such a complex system of several almost independent modules needs a
great deal of design considerations.

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.

(To make this compile with GIMP 1.1.32, use my patch at
http://www.tu-chemnitz.de/~tisc/gimpeon-0.2.2-tisc.patch.gz
which already includes Lars Claussen's patch mentioned at the page)

Bye, Tino.

-- 
             * LINUX - Where do you want to be tomorrow? *
                  http://www.tu-chemnitz.de/linux/tag/
         3rd Chemnitzer Linux-Tag from 10th to 11th March 2001 
                 at Chemnitz University of Technology!

Reply via email to