Path: utzoo!utgpu!water!watmath!clyde!att!att-ih!pacbell!ames!pasteur!ucbvax!hplabs!nsc!csi!jwhitnel
From: jwhitnel@csi.UUCP (Jerry Whitnell)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Something HyperCard *OUGHT* to do
Message-ID: <1488@csib.csi.UUCP>
Date: 27 Apr 88 19:04:27 GMT
References: <50949@sun.uucp>
Reply-To: jwhitnel@csib.UUCP (Jerry Whitnell)
Distribution: comp
Organization: Communications Solutions Inc., San Jose, Ca
Lines: 67

In article <50949@sun.uucp> landman@sun.UUCP (Howard A. Landman) writes:
>One of the most severe problems with the Mac is that every program
>assumes it is interacting with a human being. [...]
>
>A concrete example: I play the game of Go.  I have several Mac programs
>which play Go.  I have a database of game records in ASCII format.  Both
>of the following are desirable, and neither is possible without extremely
>convoluted (probably assembly language) hacking:
>
>1. Have two programs play each other.
>2. Have a program take a list of files of incomplete games, one at a time,
>   read a file in, play both sides to completion, save the result in another
>   file, and then process the next incomplete game, until all games are done.
>
>The basic problem is the use of the mouse as the primary input device,
>as opposed to a keyboard.  This makes "shell scripts" unnatural.
>I can do the above things AS LONG AS I AM SITTING THERE DOING THE
>CLICKING, but there is no way to have them happen automatically.

Actually, the input side is not that difficult.  One could write extensions
to hyperard that would drive the input side of another program by feeding
events to it.  There are a few problems involved like finding the partition
holding the program and getting the events in the queue, but nothing a
good hacker couldn't figure out.  QuickKeys is a very good example of
what you want from the input side, in that it modifies the event queue
to expand the macro and so provides automatic control of a program.

The real problem is the output side of the program.  The reason pipes
work so well in UNIX is that all output from a program is a stream of
bytes, usually text, that can be passed around at will.  However the
output of a Mac program is much more complicated and includes not
only text but also graphics of all sorts.  In your example of Go programs,
Dragon doesn't keep a text list of its moves, it only draws them on the
board using (I assume) FillOval.  For a Hypercard script to drive two programs
playing each other, it would have to recognize the FillOval command, detirmine
from the rectangle and color which side moved and where the move was and then
generate the equivalent muse movements to pass the move to the other program.
(BTW, try to get two UNIX go programs to play each other.  Not as easy as
one might hope for :-).

This "shell" can take over all these calls and pass the information to
the Hypercard application, but then you'd have to reverse engineer each
program to see how it generated each of its displays, so that your program
can read it and respond in the appropiate fashion.  Hypercard applications
can be written to support this, however.   This would be more difficult to
implement that it needs to be because Hypercard doesn't support IPC (Inter-
Process Communication), so you'd have to hack your own together.

There are some existing tools that may make this easier.  Both QuickKeys
from CE Software and Tempo II from ? provide input macro capability. 
I've heard that Tempo II also has a programming interface that could
be used for this purpose.

> ...
>Any comments (besides "Why didn't *I* think of that?")?

The general idea has existed for awhile (Andy Hertzfeld wanted to put
something like it in Servent, but I think Servant is dead), but your
the first to suggest using HyperCard as the driver.

>
>	Howard A. Landman


Jerry Whitnell				Been through Hell?
Communication Solutions, Inc.		What did you bring back for me?
						- A. Brilliant