john13@garfield.UUCP (08/12/87)
-- 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) <exit dpaint, the screen stays open> <do more stuff to screen from CLI> 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
rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (08/15/87)
$ 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) $ <exit dpaint, the screen stays open> $ <do more stuff to screen from CLI> $ makeimage 10 10 100 25 "df0:image.h" (grab section as C source code) Will Bill Hawes' REXX, most of the above is a 60-line program in C. It simply opens a message port and waits for messages; parses them and does does what they want. If you add an IFF reader, then get get the images. Add a REXX message port to Dpaint, and you get the dpaint command. (Or some sort of command line option.) And once you have int installed, it is accessible from anything with a REXX message port, including the interactive REXX listener! Willy wrote a very short and very impressive demo program for the Amiga using about 60 lines of REXX, his screenmaster code described above (our `draw: device'), and REXX. If you are interested in REXX (which you should be), please call Bill Hawes at 617 568-8695. -tom
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (08/19/87)
In article <492@rocky.STANFORD.EDU> rokicki@rocky.UUCP (Tomas Rokicki) writes: >In article <> someone_else typed: >> >> As far as my suggestion for a Draw: device goes, my dream would be to use it >> as follows: [dream follows] > >With Bill Hawes' REXX [your "Dream comes alive!" (Hi, Pixar :-)] > >If you are interested in REXX (which you should be), please call Bill >Hawes at 617 568-8695. The key to REXX's success will be a critical mass of programs that have REXX interface ports. I wish that Bill Hawes would widely distribute a sample REXX application that does something like: Open a custom screen Allow the mouse-user to draw rubber-band lines. And include a second REXX program that: Calls the first program to draw a bunch of lines, corresponding to some mathematical formula. Include on that disk descriptions, include files and samples of how to add REXX to *your* program. Since REXX is a commercial product, a person adding a REXX port to their program would still need to buy the actual REXX disk and manual... so the address, price and phone number of Bill's company would need to be included. Send free copies to Electronic Arts, Ageis, MicroIllusions, Terrapin, etc. Think if Dpaint III has a REXX interface... that would sell at lot of REXX. Bill gave a talk on REXX at a BADGE meeting. I feel it was a weak presentation in that it gave near-zero developer type information at a meeting of the "Bay Area Developer's GroupE". Again, REXX is a minimal addition to a program; but it has to be added. I wanted to add REXX to a program... but I could not easily get the information, and thus have not done it. ----- |\ /| . Ack! (NAK, EOT, SOH) {o O} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U "Success leads to stagnation; stagnation leads to failure."
scotty@l5comp.UUCP (Scott Turner) (08/23/87)
In article <3878@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >-- >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) All the above looks good till you take an eye to actually creating such a draw: handler. First, what do you think is going to happen when you type in draw:create...? The CLI is going to try and load draw:create as a program and execute it. Do you propose having the handler return a "dummy" program to run which will then be passed the parameters? Because a) otherwise you'll get an error, nasty for exec files b) the 320 200 32 df0:palette will NOT be passed to the handler, they'll be passed to the program... Alternate proposal: touch draw:create/320/200/32/df0:palette touch draw:load/df0:picture copy df0:obj_description to draw:object touch draw:arc/0/0/300/200 The /'s are needed so all params get passed to the handler. But the above still isn't workable I think. the df0:palette and df0:picture would be a problem due to the embedded :'s I think. >dpaint (edit *that screen* with dpaint) OK, so we would give dpaint what for a filename so it can edit that picture? draw:save? But that violates the draw:load/filename concept... How about we fix that by: copy df0:picture to draw:load? That bags up one of them nasty :'s. But then another thought occurs to me. What do we do with the screen info embedded in the IFF file? Like the color map etc We also leave open: copy df0:picture to draw:load/10/10/100/100/0/0 This would extract a rectangle 10/10/100/100 from the picture at 0/0 and paste it into our draw:screen. We could slap on two more digits so we could say where in the screen to slap it in at too eh? While we're at it why not: copy df0:palette to draw:create/320/200/32 Then we nail the last :. >makeimage 10 10 100 25 "df0:image.h" (grab section as C source code) How about: copy draw:savec/10/10/100/25 to df0:image.h Which would also imply: copy draw:save/10/10/100/25 to df0:image.iff Which would also imply: copy draw:savec to df0:alltheimage.h And for the laser printer fans out there: copy draw:savep to df0:image.postscript Much nicer though would be to have named pictures so that multiple draw's could be open at once. Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan "Pirated software? Just say *NO*!" S. Turner
john13@garfield.UUCP (08/27/87)
In article <329@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes: [ syntactical and implementation notes for a "graphics-handler" ] >Much nicer though would be to have named pictures so that multiple draw's could >be open at once. Naming pictures is a win, with the easiest way being to use an actual screen or window name and having the Intuitionbase->FirstScreen to scan for that name. As far as informing DPaint about some pre-existing graphics memory to work on, I can imagine having a window named "Address = $00370a0" just so I have the address of the rastport structure for reference. So "dpaint -address $00370a0" becomes possible (although this looks ugly even to me, I'll do anything to be able to draw a better picture with less work :-). Using programs like copy, type, and such to pass info back and forth is of course highly desirable. I guess these would always be necessary from the CLI, while opening a "draw:foo" file and reading/writing to it would be the preferred mode of access from within Basic, C, Modula, Lisp, Forth, Smalltalk et al. Hmmm, yeah, I'll write my fractal code in Lisp, that's the ticket. So what if this version doesn't support graphics - all you need be able to do is calculate coordinates and write to a file. John -- "Gimme ten puddings." -- Dan Fielding