Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!mimsy!steve From: steve@mimsy.UUCP Newsgroups: comp.windows.misc Subject: Re: every icon is an object Message-ID: <6787@mimsy.UUCP> Date: Tue, 26-May-87 16:36:29 EDT Article-I.D.: mimsy.6787 Posted: Tue May 26 16:36:29 1987 Date-Received: Thu, 28-May-87 01:01:54 EDT References: <8705190042.AA14664@cogsci.berkeley.edu> <9954@decwrl.DEC.COM> <868@gvax.cs.cornell.edu> Reply-To: steve@mimsy.UUCP (Steve D. Miller) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 56 In article <868@gvax.cs.cornell.edu> jqj@gvax.cs.cornell.edu (J Q Johnson) writes: [ ... ] >One problem with the "feeding the object" primitive: how do you specify >where output should go? In ViewPoint, destination is hardwired into the >particular process icon. For example, an ascii-to-internal converter >always makes another icon on the desktop, while a printer always sends the >output to a physical laser printer. How could one usefully extend the >"feed to by dropping on top of" metaphor to UNIX-style pipes? There was an interesting paper presented at the Summer 1986 Usenix (the one in Atlanta). It was entitled, "A Data-Flow Manager for an Interactive Programming Environment," and was written and presented by Paul E. Haeberli of Silicon Graphics, Inc. In this paper and presentation, the author described a set of simple changes to a window-based environment that I feel was the best mix of pipes and windows that I've ever seen. (Not that I've seen all that many, though.) The idea was that programs could be written to provide all sorts of inputs and outputs... all of which had associated with them information as to what input was expected or what output was provided. The window manager provided a visual paradigm by which tools could be tied together. There was some mouse function that popped up menus containing the names of the various inputs and outputs for a given tool, and the actual connections were displayed as lines/pipes on the screen. The pipe information could be hidden so that it wasn't always in the way -- something which I thought was a nice touch. Haeberli showed a videotape in which he (or someone else, but I'll assume it was him) took a tool that provided rotation and translation information, a tool that provided images, and a tool that displayed images, and tied these simple tools together to build a tool that could display an arbitrary image under arbitrary rotations and translations. The final tool was something that would have been quite time-consuming to code as a unit, but each tool itself was quite simple. It was *awesome*. I was impressed, and I don't think that I was the only one. I don't think there was any hard-core typing information associated with the input and output streams, but I'm not sure. Even if there wasn't, I'm not sure that the results of feeding a x-y-z output into an input that was expecting an image would be any worse than, say, cat'ing a raw disk device into troff's stdin. Some special coding within tools is required, but special coding (admittedly, not a lot of it) is required to use stdin and stdout, too. The implementation sounded quite simple, too. I wouldn't put it past someone to knock out a simple version using Your Favorite Window System For Which You Have Source and sockets of some flavor or another in a couple of months at the outside. (Of course, there's probably some subtleties here that I'm missing and that make the problem much harder.) If anyone does an implementation for SunView, NeWS, or X, I'd love to take a look... -Steve -- Spoken: Steve Miller ARPA: steve@mimsy.umd.edu Phone: +1-301-454-4251 CSNet: steve@mimsy.umd.edu UUCP: {seismo,allegra}!mimsy!steve USPS: Computer Science Dept., University of Maryland, College Park, MD 20742