🚀 go-pugleaf

In article <9954@decwrl.DEC.COM> karlton@decwrl.UUCP (Philip Karlton) writes:
>	boring!jack@cogsci.berkeley.edu (Jack Jansen) writes:
>>If you view every icon as an object that can be activated, there
>>are only two primitives that you need to do almost everything:
>>- Activating an object ...
>>- Feeding an object ...
>You might try taking a good look at the design for Xerox Star user interface.
>It first became commercially available in 1980 or 1981. The implementation had
>more than one performance bug.

Actually, the Star interface, and its successor ViewPoint (which has
fewer performance problems) has at least 3 primitives:
opening/activating, feeding to another icon, and examining/changing
properties.  Typical properties of an object include the name of a
file, the generation retention count of a directory, and switches that
one might want to pass to a particular program.  Seems to me this third
generic primitive is extremely important in an icon-based system as a means
of setting defaults.  It also nicely parallels the property-setting
functions of a typical wysiwyg editor.  For example, in ViewPoint the
same "PROPS" key is used to set properties of icons and properties of text
within the editor (text properties include all sorts of things--font,
line spacing, width and dashing of graphics, number of columns in a table,
etc.

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?