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
> 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
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
which already includes Lars Claussen's patch mentioned at the page)
* LINUX - Where do you want to be tomorrow? *
3rd Chemnitzer Linux-Tag from 10th to 11th March 2001
at Chemnitz University of Technology!