Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!utcsri!utegc!utai!garfield!john13 From: john13@garfield.UUCP Newsgroups: comp.sys.amiga Subject: Program-independent rastports Message-ID: <3878@garfield.UUCP> Date: Wed, 12-Aug-87 15:25:56 EDT Article-I.D.: garfield.3878 Posted: Wed Aug 12 15:25:56 1987 Date-Received: Sat, 15-Aug-87 12:07:41 EDT Organization: CS Dept., Memorial U. of Newfoundland, St. John's Lines: 35 -- As far as my suggestion for a Draw: device goes, my dream would be to use it as follows: draw:create 320 200 32 df0:palette (create custom screen) draw:load df0:picture (loads iff file into custom screen) copy df0:obj_description to draw: (plop on some pre-calced polygons) draw:arc 0 0 300 200 etc (send various drawing commands) dpaint (edit *that screen* with dpaint) makeimage 10 10 100 25 "df0:image.h" (grab section as C source code) It seems to me that screens which can be altered by many programs, and don't close when the programs exit, could be very helpful. Especially with a lot of graphic tool utilities; and if these utilities are keyboard oriented, why write a program that accepts keyboard input in a flexible manner when we already have command history and editing, aliases, environment variables, etc available through the regular system interface? Why not "copy *.object to draw:" or "draw:merge $pic1 $pic2 xor"? This may sound like a pipe-dream, but the features of DPaint II would have seemed that way to me a year ago. This way, you get to keep the convenience of the CLI and its utilities, while using drawing routines that sit quietly around in the filename space, taking the requests as they come. And anything generated this way would be *much* more responsive to being redirected to, say, a 300 DPI laserprinter. Like the one at work :-). John -- "She's sort of a 'pit baby', with interlocking jaws. We feed her on chicken parts." "But baby-fighting has been outlawed, hasn't it?" -- Tracy Ullman describing her infant daughter to David Letterman