oz@yunexus.UUCP (Ozan Yigit) (08/07/88)
In article <1220@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: > >Pipes should work just fine with icons. Better, even. You should just be able >to grab your file, awk, grep, hook them together with rubber band lines, >and hit "go". I'm amazed that nobody has implemented this yet. > See 1986 Atlanta Usenix Conference proceedings for a neat implementation of the concept, where multiple pipes (tee^n?) were implemented also. oz -- Crud that is not paged | Usenet: ...!utzoo!yunexus!oz is still crud. | ....!uunet!mnetor!yunexus!oz andrew@alice | Bitnet: oz@[yulibra|yuyetti] | Phonet: +1 416 736-5257x3976
les@chinet.chi.il.us (Leslie Mikesell) (08/08/88)
In article <835@yunexus.UUCP> oz@yunexus.UUCP (Ozan Yigit) writes: >In article <1220@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >> >>Pipes should work just fine with icons. Better, even. You should just be able >>to grab your file, awk, grep, hook them together with rubber band lines, >>and hit "go". I'm amazed that nobody has implemented this yet. >See 1986 Atlanta Usenix Conference proceedings for a neat implementation >of the concept, where multiple pipes (tee^n?) were implemented also. Hmmm, could they really pick out, say 'tr', from 2 or 3 hundred similar tools faster than typing the name in? What about command line options? Most tools need more than a filename. If selecting the icon would then present a form of choices for arguments and do some error checking before going on to the next tool, there might be some advantage. Les Mikesell
grogers@m.cs.uiuc.edu (08/09/88)
Anyone interested in this idea should also check out Paul E. Haeberli, "ConMan: A Visual Programming Language for Interactive Graphics", Computer Graphics, Vol. 22, No. 4, SIGGRAPH 1988. The title is really misleading, this work is not at all a programming language. It is a multidimensional pipe mechanism for putting together graphics applications. Typical tools include a curve editor, curve-to-surface sweeper, recorder (for animations), renders, and transformation controllers. You should also look at James M. Purtilo, "Polylith: An Environment to Support Management of Tool Interfaces", Proceedings of the ACM SIGPLAN Symposium on Programming Issues in Programming Environments, Jun 1985. J. M. Purtilo, "A Software Interconnection Technology To Support Specification of Computational Environments," Dept. of Computer Science, University of Illinois, Report number UIUCDCS-R-86-1269, Sept. 1986.
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (08/09/88)
In article <6246@chinet.chi.il.us>, les@chinet.UUCP writes: > Hmmm, could they really pick out, say 'tr', from 2 or 3 hundred similar > tools faster than typing the name in? What about command line options? > Most tools need more than a filename. If selecting the icon would then > present a form of choices for arguments and do some error checking before > going on to the next tool, there might be some advantage. For a good implimentation(sp?) of how to have command line options and icons living together, check out the way it's done on the (gak, gag, gawk, etc) Atari ST under the GEM desktop. Essentially, the shell knows which files require command lines, and open a window which lets you type it in. I still would rather have a text based shell for any _real_ work, though I often use a WIMP interface to often used tools which require no command line arguments. -- -------- Christopher J. Calabrese AT&T Bell Laboratories ulysses!cjc
allbery@ncoast.UUCP (Brandon S. Allbery) (08/10/88)
As quoted from <10498@ulysses.homer.nj.att.com> by cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]): +--------------- | In article <6246@chinet.chi.il.us>, les@chinet.UUCP writes: | > Hmmm, could they really pick out, say 'tr', from 2 or 3 hundred similar | > tools faster than typing the name in? What about command line options? | > Most tools need more than a filename. If selecting the icon would then | > present a form of choices for arguments and do some error checking before | > going on to the next tool, there might be some advantage. | | For a good implimentation(sp?) of how to have command line options | and icons living together, check out the way it's done on the | (gak, gag, gawk, etc) Atari ST under the GEM desktop. +--------------- The MacOS already knows about multiple entry points in an application (read: program), so it shouldn't be too much trouble for a pipe-stringing mode (in System 8.0, which is supposed to have fully pre-emptive process scheduling instead of the MultiFinder hack) to open the application in "dialog" mode, where it can pop up a dialog box to get any necessary arguments via the usual menu/field/button/etc. interface. (Maybe some enterprising A/UX hacker -- if such exist yet -- could try implementing this?) ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc