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!
