🚀 go-pugleaf

In article <2187@emory.uucp> arnold@emory.UUCP (Arnold D. Robbins {EUCC}) writes:
>
>There exists a notation to do this in ksh-i, the latest version of ksh. To
>use it though, your Unix must have the V8 /dev/fd  mechanism (keep an eye
>on comp.sources.unix for a driver for 4.3 & NFS systems, from me, originally
>from Fred Blonder). Anyway the notation is
>
>	sort (awk) (sort | grep)
>
>The ()'s enclose a shell pipeline, if preceded by a '<' or left alone,
>the pipline's output is connected to a file in /dev/fd passed as the argument
>to the program. The file will be the read end of a pipe, so sort would
>see, e.g., "/dev/fd/4" and "/dev/fd/5" for its arguments, awk and the 
>sort|grep pipeline would write on the other side of the pipe.
>
>Arnold Robbins

You can also implement this on a system that has FIFO special files. This
has the advantage that the filenames that are passwd to the program are
not forced to be of that special form /dev/fd/[number] - anything will do,
so long as you can mknod a fifo with that name! This is useful for programs
which insist on their filename parameters having special suffixes (such as
cc, ld, tex, etc...). 
The only problem is thinking of a notation for allowing a filename to be
given, if required, on the command line to be associated with a command.
Something like (#filename command) is pretty gross, but I can't think of
anything better. It does mean you can type straight into cc though, with
	cc (#x.c cat)
(which cats from stdin into a fifo called x.c, and cc is called with this
fifo as its argument).

Another problem is that the fifo has to be removed when the command is
finished - which can cause problems when the command is put in the background.

	%{
	    Simon.
	%}
-- 
----------------------------------
| Simon Brown                    | UUCP:  seismo!mcvax!ukc!its63b!simon
| Department of Computer Science | JANET: simon@uk.ac.ed.its63b
| University of Edinburgh,       | ARPA:  simon%its63b.ed.ac.uk@cs.ucl.ac.uk
| Scotland, UK.                  |
----------------------------------     "Life's like that, you know"

In article <8705190042.AA14664@cogsci.berkeley.edu>
	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.

PK

In article <8705190042.AA14664@cogsci.berkeley.edu> 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 (double clicking). 
>
>- Feeding an object (dragging one or more other objects onto it).

Case 1: there is only feeding - you just drag the double-click onto it!

Case 2: you never know EVERYTHING you'll ever want to do with files(objects).
	The number of operations can then get VERY big - how many
	folk round here would like a GREP facility on the Mac - or
	the ability to print an object without opening the damn thing
	and hanging around for needless user interface start-up operations?
	The main flaw in the Mac is the lack of good generic
	operations on objects which test for properties.

NB: reliance on gestures for expressing all actions is not a very good
    idea. Why the hell do you think we developed spoken and written
    language? Note the major inconsistencies in the meaning of
    dragging on the Macintosh.
	
-- 
   Gilbert Cockton, Scottish HCI Centre, Ben Line Building, Edinburgh, EH1 1TN
   JANET:  gilbert@uk.ac.hw.aimmi    ARPA:   gilbert%aimmi.hw.ac.uk@cs.ucl.ac.uk
		UUCP:	..!{backbone}!aimmi.hw.ac.uk!gilbert

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?

As a user of the Xerox Viewpoint (&XDE) workstations, allow me to comment:

> One problem with the "feeding the object" prmitive: How do you specify
> where output should go?  In viewpoint, destination is hardwired into the
> particular process icon

Granted, Viewpoint hardwired it.  However, it doesn't have to be that way.  
I would seem that the properties of the printer could include a switch to 
set the destination e.g. the "chooser" on the Mac.

> For example, an ascii-to-internal converter always makes another
> icon on the desktop. ... How could one usefully extend the "feed to by
> dropping on top of" metaphor to UNIX style pipes?

Actually, not all operations in Viewpoint automatically create a new
icon on the desktop.  Some operations will convert the cursor to a small
icon, indicating that it is waiting for *you* to point & click to
where you would like the new object to appear.  This would seem to be
able to be extrapolated to a generalized system for taking output
of one process and using it as inputing into the next pipe.

I would like to raise the general question of how to best to handle
"pipes" in an icon oriented system.  I am new to this newsgroup and
this topic of discussion. If this topic has already been beaten to
death, please send me the autopsy.  Otherwise, I look forward to
hearing some new ideas.

-- Craig











-- 

	Craig Stevenson
	  The Ohio State University		ARPA: crs@Ohio-State.arpa
	  Columbus, Ohio			UUCP: ...!cbosgd!osu-eddie!crs
	  (614) 292-7347

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

In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes:
> ...
>   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.
> ...
>   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.  

	It sounds like they've re-invented (or borrowed) some ideas
from the Evans and Sutherland Picture System's environment.  As far
back as the PS-300 in 1983 or so, this sort of stuff was available,
and maybe before then or on earlier PSs.

	The native language of the box (68000-based, coupla Megs RAM)
had a Pascal-like syntax for dataflow system.  While the machine had
no window system per se (it was oriented towards fast monochrome
vector graphics), it had lots of user interface toys like knobs,
buttons, light pens, etc.

	There was a development environment (PIGS?) that allowed one
to manipulate pictures of boxes representing functional elements of a
dataflow circuit.  An instance of Rotate could be picked from a
palette, rearranged with the light pen, and outputs attached to inputs
of other boxes, the final one of which represented the display itself.
Boxes' inputs could be wired to pictures of the input devices as well,
to make Knob3 control X on the Scaling box or whatever.

	To test your system, I think there was an imbedded
interpreter, so that you could hide the diagram of your circuit and
turn on its function and play with knobs for debugging.  All this was
just a wonderful editor, that spat the native Pascal-like language out
the back for compilation when you were done prototyping.

	My details may be foggy - it was a long time ago and I didn't
know much about user interface design then (many would say I still
don't :-) and I never got the chance to use it much.  But I watched
Julian Gomez do wondrous things with it, and it really felt like The
Right Way to do what it was doing.
-=-
 Bob Sutterfield, Department of Computer and Information Science
 The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-eddie!bob
 soon: bob@aargh.cis.ohio-state.edu

gilbert@aimmi.UUCP (Gilbert Cockton) writes:
+Case 2: you never know EVERYTHING you'll ever want to do with files(objects).
+        The number of operations can then get VERY big - how many
+        folk round here would like a GREP facility on the Mac - or
+        the ability to print an object without opening it...
Just like to point out that you can easily print an object without going 
through a lot of user-interface interactions: just select one, or a group
of objects in the finder, and choose "Print" from the Finder's "File" menu.
It starts up their owning application, and hands them to it along with a
print message. Applications that conform to the Macintosh user interface
guidlines (and more than 95% do) will print the documents and quit without
further interaction from you other than confirming that you want a single
copy of all pages at the same print quality as last time (which you do by
either a single mouse click or a single <return> key press.

--- David Phillip Oster         -- "The goal of Computer Science is to
Arpa: oster@lapis.berkeley.edu  -- build something that will last at
Uucp: ucbvax!ucblapis!oster     -- least until we've finished building it."

Summary:

Expires:

Sender:

Followup-To:


In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes:
>[..]
>If anyone does an implementation for SunView, NeWS, or X, I'd love to
>take a look...
>
>	-Steve

I'm working on something like this (actually, The Interconnection of Highly
Interactive Software Modules) right now, supported by the UK Science and
Engineering Research Council. An actual product is not the aim of this
research - we are in the early stages yet - but there may be a by-product.
Please email me if you are interested.

Robin Faichney        rjf@uk.ac.ukc        ...mcvax!ukc!rjf

In article <3614@osu-eddie.UUCP> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes:
>In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes:
>	It sounds like they've [Haeberli] re-invented (or borrowed) some ideas
>from the Evans and Sutherland Picture System's environment.  As far
>back as the PS-300 in 1983 or so, this sort of stuff was available,
>and maybe before then or on earlier PSs.
>[...]
>	There was a development environment (PIGS?) that allowed one
>to manipulate pictures of boxes representing functional elements of a
>dataflow circuit. [...]

Probably folks from E&S are more competent to comment on this, but unless
I'm mistaken, you're referring to the "network editor" written by Dave
Schlegel.  I used it a few times;  not too novice-friendly, and was a little
slow, but very sophisticated.  Also necessary, since the "Pascal-like"
language has approximately the feel of assembly language, what with dozens
of little connection numbers that all have to match up!  I don't think the
dataflow language of the PS-300 is sufficiently appreciated by the language
community - I found that programming dataflow seems to need some rather
strange synchronization-type operators of a sort never mentioned in the
literature...  The language is quite powerful - Sandra Loosemore wrote a
flight simulator complete with SLC streets and the Wasatch mountains.
The whole thing runs locally in the PS-300!

							stan shebs
							shebs@cs.utah.edu

@eagle.ukc.ac.uk> rjf@ukc.ac.uk (R.J.Faichney) writes:
>In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes:
>>[..]
>>If anyone does an implementation for SunView, NeWS, or X, I'd love to
>>take a look...
>>
>>	-Steve
>
>I'm working on something like this (actually, The Interconnection of Highly
>Interactive Software Modules) right now, supported by the UK Science and
>Engineering Research Council. An actual product is not the aim of this
>research - we are in the early stages yet - but there may be a by-product.
>Please email me if you are interested.
>

I've  since  come  to  the  conclusion  that,  in  the  cir-
cumstances,  not  to  utilise the massive net.brainpower out
there would be a criminal  waste  of  resources.  So,  below
you'll  find  a  little more detail on what I'm doing, and I
hope that it will stimulate further discussion, even if only
to tell me that I'm barking up a gum tree.

The general idea is to design and implement a pipe  analogue
for  graphics-interfaced (WIMPS) programmes. Now, the reason
why you can't simply send the output of one  WIMPS  prog  to
the  input  of another, is that instead of being a character
stream, as in the good old days, it's all sorts of rasterops
and similar assorted nasties. But, if the prog is structured
properly (you never know) then all this  graphics  stuff  is
confined  to  the  user  interface.  (For simplicity, say we
confine it to text manipulating progs for the  moment.)  The
application  functionality,  and  therefore  the application
(using the word here as opposed  to  user  interface)  func-
tions,  should  be exactly as in the old glass-teletype ver-
sion.  So why not grab information between application func-
tions and user interface, and send it off to the other progs
app func, bypassing both UIs?

What I'm actually proposing here, is that, given  some  sort
of  interconnection standard, and perhaps an interconnection
toolkit analogous to a UI toolkit, a third layer  is  inter-
posed  between  UI and app func, which will allow any two or
more  progs  appropriately  designed  and  implemented,   to
exchange  data  and/or  commands  to  their  hearts content.
(Thanks to Gilbert Cockton for the  three  component  model,
though  his  was  intended to solve different problems.) The
app func won't know whether anything it gets is coming  from
'its own' UI, or another prog altogether (or maybe a command
file), and the UI won't know whether what it's  handling  is
going to 'its own' app func and/or another prog and/or being
written to a command file.

It's difficult to  envisage  any  sort  of  widely  accepted
interconnection  standard  in the foreseeable future, but at
least producers of software tools (like our  Software  Tools
Group here at UKC) might find this a practical way of ensur-
ing that their own products  can  communicate,  should  they
wish  to  do  so - and it's a fairly safe bet that many more
than at present would wish to do so, if they thought it  was
practical.

So - what I want to know is, are my colleagues merely  being
nice  to  me, or is this a good idea? Any and all comments -
especially on what facilities you'd like to see in an inter-
connection   toolkit  (I  already  have  an  interconnection
server: a sort of computer program dating  bureau)  and  how
these  might  be  implemented - gratefully received. Post or
email as you think fit.

Robin Faichney     rjf@uk.ac.ukc   ...mcvax!ukc!rjf

I think we need some perspective on what we're trying to accomplish.  I believe
our goal is to design a *simple* yet powerful user interface.  Neither the
Mac/VP icon interface nor UNIX shell/pipes provides ultimate power.  For
example, I've often wished that I could more easily do Teeing and pipefitting
in shell programs. [see PS below].  But for many purposes pipes, with their
single input and output streams, are a very nice metaphor for program
decomposition; they aren't powerful, but they are powerful enough and
they are simple to understand.  Similarly, "opening" and copying into
another icon are simple metaphors for complex operations, ones we know
from experience that even an intelligent 3 year old can understand.

I don't think we understand user interfaces well enough to design a simple
icon-based interface with the power of the various graphical programming
languages I've seen.  The question from my perspective is whether we can
easily extend the Mac/VP interface, which we KNOW is easy for novices to
understand.  The extensions must be very clean and elegant, yet must provide
major increases in power.

So far, the best extension I've heard that provides pipes is a general
convention that some icons are filters, and that depositing on a filter
icon will pop up an output icon next to it.  Problems:
     1/ if that space on the display is already occupied, a more complex
	scheme for the placement of the output icon is needed.  This makes
	it very hard to design a macro language (programming by example), since
	the macro can't use relative placement to find the output icon.  Note
	that what I'm really saying is that I want not just UNIX pipes but
	a shell as part of my icon-based system.
     2/ being totally icon-based is fairly noninteractive.  It works well
	for pipe examples that could substitute a temporary file (i.e.
	in which "a|b" is equivalent to "a>/tmp/$$;b</tmp/$$") but what about
	filters like "more" or "tail -f" (using tail to look at a growing log
	file).
	
P.S. on pipefitting:  my most recent problem was wanting to write a shell
script that would concatenate stdin and an internally generated header.
I had program "headergenerator" already.  So I could do:
	#! /bin/sh
	headergenerator $@ >/tmp/foo
	cat /tmp/foo -
But using a temporary file for such a simple problem was inelegant.

In article <3054@eagle.ukc.ac.uk> rjf@ukc.ac.uk (R.J.Faichney) writes:
>In article <3042@eagle.ukc.ac.uk> rjf@ukc.ac.uk (R.J.Faichney) writes:
>>In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes:

Perhaps we need a group, comp.ui for user interfaces.  Or will the windows
groups handle it?

John Carlson

Internet:  carlson@lll-tis.arpa
UUCP:		lll-lcc!lll-tis!carlson

Last week, Steven Pemberton and I did some brainstorming about
icons, user interfaces, pipes, etc. triggered by the recent discussions.

We came up with some ideas:

- There's a difference between doing something to the object (i.e. executing
it) and to the meta-object (i.e. renaming it, write-protecting it).
Our idea was to let clicks in the icon refer to the object, and clicks
in the title bar to the meta-object. This is similar to what the Mac does
(when you've selected an icon and move the mouse to the title string, you
can edit it), but more general. I.e. No more 'show info' menu: double-clicking
on the title bar will bring up the info menu.

- Usually, you don't need to specify where the output of a program goes.
Either the program has no output, the output is the same as the input
(e.g. editors), or the output file name is constructed from the input file name.
So, for most cases, selecting all input files and dragging them to the
application is good enough.

- If you *do* want to specify the output file, or certain flags, options, etc.
you double click the application icon. This will make it grow into a box
which contains buttons, etc. for options, and various icons for the input
file, output file, etc. Now, you can set uptions, drag the output icon
to where you want your output to go, drag your input files to the input icon, etc.

Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do:
	double-click ls
	double-click pr
	drag pr output icon to printer icon
	drag ls output icon to pr input icon
	select a and b and drag them to ls input icon

- There are two things we didn't really figure out how to do nicely.
First is 'move'. Copy is simple (you grab the file, and feed it to the
destination disk/directory), but move is slightly different. Shift-drag
seems to be a good candidate, but if you want your UI to be orthogonal
this means that shift-dragging a file to an application program would
delete the file. This is bound to make you lose a lot of files.

Second is the difference between starting an application without parameters
at all and 'opening' an application to be able to specify the parameters
in detail. Both of these are candidates for double click on the application.
-- 
	Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
	The shell is my oyster.

We've done some work here at UofT on a system that allows you to interactively
wire up icons on the screen to perform some task.  The icons can represent
programs or physical devices like keyboards and D/A converters.  We've used
it to control a music synthesizer, and to build a filter simulation package.
We've been calling the idea Virtual Patch Cords (VPC).

In looking around, we have discovered at least half a dozen other systems
that have the same flavour.  Here is a partial list of the papers we know
about.  If anyone has some more that could be added to the list, please
let us know.

%A David Blythe
%A John Kitamura
%A David Galloway
%A Martin Snelgrove
%T Virtual Patch-Cords for the Katosizer
%J International Computer Music Conference 1986
%P 359-363
%I Computer Music Association
%C San Francisco, CA
%D Oct 1986
%K virtual patch cords ICMC
%X An object-oriented graphics system is presented which allows a musician
to program a very versatile signal processor/synthesizer by drawing a block
diagram of the desired 'patch'.

%A David Galloway
%A David Blythe
%A Martin Snelgrove
%T Graphical CAD of Digital Filters
%J IEEE Pacific Rim Conference on Communications, Computers and Signal Processing
%C Vancouver, BC
%D June 1987
%K virtual patch cords digital filters
%X A system that allows a filter designer to wire together basic filter
elements on the screen, then watch them react to simulated inputs.

%A Peter Desain
%T Graphical Programming in Computer Music: a Proposal
%J International Computer Music Conference
%P 161-166
%I Computer Music Association
%C San Francisco, CA
%D Oct 1986
%K direct manipulation virtual patch cords ICMC
%X Lisp based graphical environment for building up patches.
Suggested application is programming of signal processors, but no back
end implemented.
Discussion of direct manipulation versus conversational metaphors, advantages
and disadvantages thereof.
Other suggested applications: studio patches, music composition, UNIX pipes.

%A Andrea A. diSessa
%T Notes on the Future of Programming: Breaking the Utility Barrier
%E Donald A. Norman and Stephen W. Draper
%B User Centered System Design: New Perspectives on Human-Computer Interaction
%P 125-152
%I Lawrence Erlbaum Associates
%C Hillsdale, NJ
%D 1986
%K device programming virtual patch cords boxer direct manipulation
%X Mainly an article on Boxer, a replacement for Logo at MIT.
Contains 2 page description of "device programming", which fits virtual
patch cords to a tee.

%A Paul E. Haeberli
%T A Data-flow Environment for Interactive Graphics
%J Proc. of the Second Computer Graphics Workshop
%P 1-12
%I USENIX Association
%C El Cerrito, CA
%D December 1985
%K virtual patch cords
%X A set of slides given at a talk.  Describes a virtual patch cord system
for an Iris.
Contrasts virtual patch cords and the UNIX shell.
Intended for use in a graphical editing environment, with sliders, recorders,
2 and 3D curve editors, etc.
No implementation at the time.

%A Paul E. Haeberli
%T A Data-Flow Manager for an Interactive Programming Environment
%J USENIX Summer Conference Proceedings
%P 419-428
%I USENIX Association
%C El Cerrito, CA
%D June 1986
%K virtual patch cords
%X An expanded description of virtual patch cord work at Silicon Graphics.
Description of implementation.  Comparison to UNIX shell.
Applied to graphical editing environment.
No macros yet.

%A Byte
%T Labview: Laboratory Virtual Instrument Engineering Workbench
%J Byte Magazine
%P 84-92
%D Sept 1986
%K VPC virtual patch cords
%X This system is very close to VPC, but is oriented towards real time instrument
control, over GPIB.
It has hierarchy and a full set of programming primitives, including looping
and recursion.

In article <879@gvax.cs.cornell.edu> jqj@gvax.cs.cornell.edu (J Q Johnson) writes:
>I think we need some perspective on what we're trying to accomplish.  I believe
>our goal is to design a *simple* yet powerful user interface.  Neither the
>Mac/VP icon interface nor UNIX shell/pipes provides ultimate power.  For
>
>So far, the best extension I've heard that provides pipes is a general
>convention that some icons are filters, and that depositing on a filter
>icon will pop up an output icon next to it.  

There IS one metaphor in common use on the Mac system which handles more
complex types of operation: the palette.

For example, in Macpaint, Macdraw etc. the user selects a tool from the
palette and then clicks in the drawing pane.  The exact meaning of the
click depends of course on the individual tool.

We could have each filter be represented by an entry in the filter palette.
The standard user interface for such a filter tool is to connect two (or
more) icons in the desktop.  The first click would select the source
icon and the when the mouse is released (or the second click depending on
your preferences) the mouse should be over a target icon.  If it is not
over a target icon then a new output object is created.

Connecting the results of several filters is accomplished by
sucessive selection of different filters from the palette.  In a truly
multitasking system the first filter operation is executed while the user
makes up his mind what to do next.



-- 
                                                Department of Computing
                                                Imperial College
 Janet: fgm@uk.ac.ic.doc                        London, SW7 2BZ
 UUCP:  ...{backbone}!doc.ic.ac.uk!fgm          England
    

>Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do:
>        double-click ls
>        double-click pr
>        drag pr output icon to printer icon
>	 drag ls output icon to pr input icon
>        select a and b and drag them to ls input icon

Not quite so.  This approach seems to require a lot more
physical movement by the person using it.  Typing the command
is almost effortless.  I don't mean this as a condemnation of
window/icon systems in favor of command-line interpreters, but
I am interested in finding a visual paradigm that is *at least*
as easy and powerful for simple and complicated tasks as a CLI.

My major problem with this paradigm is verifiability.  Suppose, just
before the final step, I suddenly think that I've made an error.
With the CLI version, I can re-read the command, and see if it looks
right.  With your approach, there is no evident control flow.  You
set up the right abstract pattern on the screen, and the right things
happen.  If you get the pattern right....

--Tom

In article <7405@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes:
>
>Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do:
>	double-click ls
>	double-click pr
>	drag pr output icon to printer icon
>	drag ls output icon to pr input icon
>	select a and b and drag them to ls input icon
>
The problem with selecting a and b is that how do you tell the
application that there are no more parameters, and it should start
working.

> >So far, the best extension I've heard that provides pipes is a general
> >convention that some icons are filters, and that depositing on a filter
> >icon will pop up an output icon next to it.  

This is basically a dataflow system. I suggested something like this a couple
of years ago and watched it vanish without a trace. One thing to consider is
that some filters have more than one output... for example "tee". Some filters
have more than one input, for example "diff". The actual mechanism for
building the picture may vary, but the result should look something like
this:

	------     ---------------
	|FILE|-->--| IN  |       |
	|___/      |     | DIFF  |
	------     -------_______|     -------------------     ------
	|FILE|-->--| IN  | OUT   |-->--| IN  | TEE | OUT |-->--|FILE|
	|___/      |_____|_______|     -------------------     |___/
				             | OUT |
				             -------
						|
						V
						|
					     -------
					     |LPR2 |
					     \__,--'

The problem comes from the idea of icons being non-atomic. Would you start
things up by putting the DIFF in, then dropping the files into its input
baskets? Perhaps having pipelines permanently affixed to the icon and
you connect them tinkertoy fashion?

While you're looking at examples of wiring up icons to do jobs, don't miss
the educational program "Rocky's Boots", appearing on a home computer near
you.  If it's simple enough for kids to do, it can't be all bad.

Kent.
--
Kent Paul Dolan, LCDR, NOAA, Retired; ODU MSCS grad student	 // Yet
UUCP  :  kent@xanth.UUCP   or    ...{sun,harvard}!xanth!kent	// Another
CSNET :  kent@odu.csnet    ARPA  :  kent@xanth.cs.odu.edu   \\ // Happy
USPost:  P.O. Box 1559, Norfolk, Virginia 23501-1559	     \// Amigan!
Voice :  (804) 587-7760    -=][> Last one to Ceres is a rotten egg! -=][>

In article <1205@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes:
>
>While you're looking at examples of wiring up icons to do jobs, don't miss
>the educational program "Rocky's Boots", appearing on a home computer near
>you.  If it's simple enough for kids to do, it can't be all bad.

I've never tried Rocky's Boots, but I have tried a similar program called
Robot Odyssey.  In that program you have to write up robots to perform tasks
for you.  The reasons is that you are stuck in an underground world and are
trying to get out of it.

You wire circuits to control the robots' thrusters, sensors, radio, etc.
You have a limited supply of components, so you also have to burn chips.
(Burning a chip creates a compiled version of your circuit, and allows you
to reuse its componenets.)

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com

In article <454@ivax.doc.ic.ac.uk>, esh@doc.ic.ac.uk (Edward Hayes) writes:
> In article <7405@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes:
> >Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do:
> >	double-click ls
> >	double-click pr
> >	drag pr output icon to printer icon
> >	drag ls output icon to pr input icon
> >	select a and b and drag them to ls input icon
> >
> The problem with selecting a and b is that how do you tell the
> application that there are no more parameters, and it should start
> working.

A "GO" icon?

Any structure you build should be editable. Thus, you could do this:

	Pick up ls. Drop it into "Build" window. Drop pr in next to it.
Click ls and pr to link them. Pick up files and printer icons. Click a, ls,
b, ls, pr, lp to hook them up. Click "GO".

If you decide not to ls b, you could pick up b and drop it back on the
desktop before you click GO.

In article <454@ivax.doc.ic.ac.uk> esh@doc.ic.ac.uk (Edward Hayes) writes:
}In article <7405@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes:
}>
}>Pipes are simple now. for 'ls -l a b | pr >/dev/lp', you do:
}>	double-click ls
}>	double-click pr
}>	drag pr output icon to printer icon
}>	drag ls output icon to pr input icon
}>	select a and b and drag them to ls input icon
}>
}The problem with selecting a and b is that how do you tell the
}application that there are no more parameters, and it should start
}working.

Click a then b with the right button, pick them both up with the right button
and drop them in place. The left button is used to pick up just one file,
and clears any outstanding right button selections.

       -Adam.

/* If at first it don't compile, kludge, kludge again.*/

Several comments on the recent discussions:

1. Paul Haberli gave a demo of his pipe-fitting system at Berkeley 18
months ago.  It was very impressive.  A student implemented a (buggy)
version of it in a user-interface class I teach here.  Paul's system
used shared files to communicate which required a kernel modification.
Our system used 4BSD sockets so no kernel mods were required.  We also
used the X windowing system rather than the silicon graphics windowing
system.
   Another student took this package and implemented some simple tools
for accessing a relational database.  I wrote a paper describing the
system.  I will be glad to send a copy of it to anyone who sends email 
to me at Berkeley. Please include your postal address.  The paper includes
screen dumps that I had to cut/paste into the text.  I seemed to have
misplaced/lost my multimedia, wysiwyg document editor....:)
   I'd be glad to send folks the code, but it is not really usable at the
moment.  The student who did the 2nd project has left and we never really 
made it run reliably.  If there is enough interest, I can probably dig up 
the code and send it to folks.  Better yet, if someone wanted to pick it 
up and work on it, I would be thrilled.

2. Interesting comment on the difficulty of publishing user interface papers.
Paul sent his original paper to 3 places before it was finally accepted by
Usenix.  I've sent my paper to 2 conferences that both rejected it (close
votes, but not good enough) and have now sent it to a third.  Neither paper
is very deep technically, and in a sense, communicate an obvious idea once
you've thought about it.  the idea is simple enough that folks can't believe
it's worth publishing.  of course, we still labor with lousy user interfaces
because ....   Sigh!

3. I too strongly support the creation of a user-interface newsgroup.  Is
someone going to do the survey?
	larry

In article <610@gec-mi-at.co.uk>, adam@gec-mi-at.co.uk (Adam Quantrill) writes:
> Click a then b with the right button, pick them both up with the right button
> and drop them in place. The left button is used to pick up just one file,
> and clears any outstanding right button selections.

Some machines have well-defined semantics for what the right button means. For
example, the Amiga knows it as the menu button. For that matter, the Amiga
has a well defined way of doing what you want:

Click a.
Hold down the shift key and click b.
keep holding down the shift key and drag a and b into the icon you want to
deliver them to.

For building pipelines, a better way would be:

Drag ls into the work window.
Drag pr into the work window.
Drag the files into the work window.

Click a, ls; b, ls; ls, pr; pr, whatever.

This connects a to ls, b to ls, ls to pr, and pr to whatever.

Then you hit the doit icon or select doit from the menu. (Oh why does everyone
have to use pull down menus when popups are so much more convenient?)
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

In article <367@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes:
>For building pipelines, a better way would be:
>
>Drag ls into the work window.
>Drag pr into the work window.
>Drag the files into the work window.
>
>Click a, ls; b, ls; ls, pr; pr, whatever.
>
>This connects a to ls, b to ls, ls to pr, and pr to whatever.
>
>Then you hit the doit icon or select doit from the menu. (Oh why does everyone
>have to use pull down menus when popups are so much more convenient?)

Why do we have to use icons for everything ?  I really see no
reason to move my mouse around, collecting icons & selecting menus,
when I can do the same thing with just a few keystrokes in a
command line interpreter.  Of course window systems have their
merits, but I think we should not try to translate our good old
unix habits into the mouse&icon language.  There are some things
that can be easily done with an icon-oriented system, like
moving files, executing application programs and such stuff.
Unix pipes are not among those.  Of course, you can use programs
and 'graphical pipes' to build up complex blocks, but the net effect
is that you've got to do MORE things to get something done, instead
of less.
A different thing, of course, are the visual pipes or filters
that someone suggested a while ago (sorry, can't find the article).
If you can take a 'grep' tool like a magnifying glass, move it over
some text, and see only the grepped text, you've got something
useful.  But none of the windowing systems that I've seen work this
way.  They all are just some kind of graphical shell with icons for
filenames, mouse moving for the mv, cp and rm commands, and mouse
clicking for the starting of programs.  These are all things I can
do just as good in a command line interface, thanks.

	Hans-Martin Mosner (hmm@unido.uucp)
	University of Dortmund
D

In article <66@laura.irb.informatik>, hmm@unido.UUCP (Hans-Martin Mosner) writes:
> In article <367@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes:
> >For building pipelines, a better way would be:
> >
> >[fairly involved method described]
> 
> Why do we have to use icons for everything ?

We don't. Some people, however, do. There are people (believe it or not)
who are not capable of dealing with anything more complex than a Macintosh.
If UNIX is to become a popular operating system (something I find desirable:
maybe you prefer everyone standardise on MS-DOS and the Mac), then there has
to be some visible advantage that anyone can see. My assertion is that a
graphical method for invoking pipelines would be something anyone can do.

Also, you can describe some pipelines graphically that you would have a great
deal of trouble expressing on a command line.

(awk)_______                                 _(one set of lines)
            \__(sort both together)|(grep2)_/
(sort|grep)_/                               \_(another set of lines)

Every now and then I come across something wierd like this I want to do.
I usually end up making temp files. Wasn't that the whole point of pipes
in the first place? You would end up with an extremely powerful dataflow
programming system.
-- 
-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)

(This is being cross-posted to comp.unix.wizards, for the more wizardly
 denizens of that group to check my "solution" and acompanying assertion,
 but followups have been directed back to comp.windows.misc only.)

> peter@sugar.UUCP (Peter da Silva)
> [...] you can describe some pipelines graphically that you would have a great
> deal of trouble expressing on a command line.
>
> (awk)_______                                 _(one set of lines)
>             \__(sort both together)|(grep2)_/
> (sort|grep)_/                               \_(another set of lines)
> 
> Every now and then I come across something wierd like this I want to do.
> I usually end up making temp files. Wasn't that the whole point of pipes
> in the first place?

I disagree that it is all that hard.  Assuming that you have a sort
program that reads from descriptors 3 and 4 for the "sort both
together", and that you have a grep that writes on descriptors 3 and 4
to generate multiple outputs, it is rendered:

        (awk)|3<&0((sort|grep)|4<&0 sort2)|grep2 3>one 4>another

This doesn't seem all that arcane to me.  Further, it can even be done
with the standard unix tools, without the sort2 and grep2 processes,
assuming that we have a "tee" that writes to descriptor 2 when given no
arguments.  (I have such a modified tee, since I find this convenient
behavior for debugging simple pipelines.)  Here it is:

        ((awk);(sort|grep))|sort|(tee|grep x >one&)2<&1|grep y >another

Again, though this *is* arcane, it is not all *that* arcane, though in
this case we have forced the awk and the sort|grep to be sequential,
though this is not necessary.  To get the awk and the sort|grep up front
to run concurrently needs the special sort2 process or some general
purpose line-oriented wye fitting, but this is perfectly straightforward.

Assuming that the programs in the system co-operate by writing to as
many output descriptors as necessary for tee junctions, and reading from
as many as necessary for wye junctions, I think any directed acyclic
graph of dataflow can be constructed out of unix pipes and such
processes (subject only to the number of available file descriptors).  I
haven't rigorously proven this, but I'd be mildly surprised to be wrong.

Further, sysV named pipes can easily be used to solve cases with less
tractable programs (which want to be fed filenames instead of
descriptors, such as the real tee).  Using named pipes and an unmodified
tee, the example might be

        p=/tmp/pipe$$.1
        /etc/mknod $p p
        ((awk);sort|grep))|sort|(tee $p|grep x >one)&grep y $p >another
        rm $p

> You would end up with an extremely powerful dataflow programming
> system.

Shell-ese already seems pretty powerful to me.  Of course, it may not be
as conveniant or user-friendly as it might be, but it *is* powerful, and
it doesn't seem all *that* arcane.

--
"You have 15 seconds to comply."
                        --- out-of-control robot from RoboCop
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw

In article <165@xyzzy.UUCP> throopw@xyzzy.UUCP (Wayne A. Throop) writes:
>
>> peter@sugar.UUCP (Peter da Silva)
>> [...] you can describe some pipelines graphically that you would have a great
>> deal of trouble expressing on a command line.
>>
>> (awk)_______                                 _(one set of lines)
>>             \__(sort both together)|(grep2)_/
>> (sort|grep)_/                               \_(another set of lines)
>> 
>> Every now and then I come across something wierd like this I want to do.
>> I usually end up making temp files. Wasn't that the whole point of pipes
>> in the first place?
>
> [Wayne gives an involved solution using tee and multiple file descriptors.]

There exists a notation to do this in ksh-i, the latest version of ksh. To
use it though, your Unix must have the V8 /dev/fd  mechanism (keep an eye
on comp.sources.unix for a driver for 4.3 & NFS systems, from me, originally
from Fred Blonder). Anyway the notation is

	sort (awk) (sort | grep)

The ()'s enclose a shell pipeline, if preceded by a '<' or left alone,
the pipline's output is connected to a file in /dev/fd passed as the argument
to the program. The file will be the read end of a pipe, so sort would
see, e.g., "/dev/fd/4" and "/dev/fd/5" for its arguments, awk and the 
sort|grep pipeline would write on the other side of the pipe.

Such a pipeline may be written to as well:

	command | tee >(prog1) >(prog2)

would send command's output to both prog1 and prog2.

There is no existing Unix tool that corresponds to the 'grep2' in Peter's
example above.
-- 
Arnold Robbins
ARPA, CSNET:	arnold@emory.ARPA	BITNET: arnold@emory
UUCP:	{ decvax, gatech, sun!sunatl }!emory!arnold
ONE-OF-THESE-DAYS:	arnold@emory.mathcs.emory.edu

[Cross-posted to comp.misc, where it belongs, and followups pointer
that way.]

In article <555@its63b.ed.ac.uk> xsimon@its63b.ed.ac.uk (Simon Brown) writes:
<You can also implement this on a system that has FIFO special files. This
<has the advantage that the filenames that are passwd to the program are
<not forced to be of that special form /dev/fd/[number] - anything will do,
<so long as you can mknod a fifo with that name!

You can do that with the /dev/fd driver, under the exact same
constraints. All you need is the ability to get a file name that
references the correct major/minor device number. The only advantage I
see for fifos is that non-root users may be able to mknod them,
whereas they can't mknod a device.

But in practice (on BSD, anyway) that's not much of a problem. All you
need to do is create a symlink to the appropriate /dev/fd file. For
example, a couple of times I've wanted to compile stuff coming out of
a pipe. The sequence is like so:

ln -s /dev/stdin pipeout.c
<pipe of stuff> | cc pipeout.c
<repeat above until happy>
rm pipeout.c

Works like a charm.

On the other hand, the /dev/fd driver gives you /dev/stdin and
friends. These are worth having all by their lonesome, and I don't
think they can be duplicated by fifos.

	<mike
--
It's been a hard day's night,				Mike Meyer
And I been working like a dog.				mwm@berkeley.edu
It's been a hard day's night,				ucbvax!mwm
I should be sleeping like a log.			mwm@ucbjade.BITNET