Hi. This also includes "The Future of Gimp" commentary. >Tino Schwarze wrote: > > Hi Adam, > > On Thu, Dec 21, 2000 at 11:15:17PM +0000, Adam D. Moss 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). 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. That is not to say that user interfaces are unimportant -- but they are (as much as possible) independent objects of design, each with their own concerns and issues. So Gimp is not married to the GTK widget set; if some (many) ones write a QT interface, bless them. Some few others may write a native Win32 interface -- bless them too. Script languages are interfaces as well; I should think that marrying Gimp with Perl or Scheme or Script Language X should not be nearly as hard a task in the 2.x series as it had been in 1.x. What may be commonly said about "user interfaces" is that they are *any* member of the class (including your favorite script interpreter) capable of originating work requests with the 'step manager' (handing over references to typographic or structured vector graphic or pixel graphic content) and querying "presentation" black boxes about the result (if any). It may be a refreshing exercise to inventory the black box bestiary presented by Adam thus far: 1. Some are capable of interpreting references to some sort graphic content as, say, PNG files in a file system. 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. 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.' 4. Some black boxes know how to stream to external representations: perhaps they embed connections to an X server, or something that knows how to write (particular kinds of) image files. 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. If the profile of requirements call for an interactive Gimp, then some of those black boxes will be display-capable. If the profile of requirements is a batch orchestrated by a perl script, then only file reading/writing and image processing black boxes will be required. 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). 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. My two U. S. cents... Garry
