This is the README for FrontEndTool.s.tar.gz [Download] [Browse] [Up]
Introduction:
Programs such as Emacs, Mathematica, Gdb etc on NeXT have a
common feature. They all have an underlying program which runs in
standard Unix environment and a front end which parses the output from
that underlying program with a more attractive presentation usually
conforms to NextStep standard and provides inputs to the program
according to use's actions such as mouse click, mouse move etc. There
are even more programs out there which can be ported to NextStep
environment by providing the front end without rewriting the whole
program or even better, without the source code. What should be done
is simple, by creating channels to communicate with the underlying
program, then that program can be controlled by the front end.
The steps take to do this are as following:
1. Creating the pty/tty pairs so that front end can communicate with
its program .
2. Forking a child process and spawning the program.
3. Parsing the output from the program and translating user's actions
into inputs to the program.
The included toolkit is such a prototype which implements the
basic stuff for you. It will create the pty/tty pair, fork the child
process and spawn the program for you. It also provide two routines,
inputToApp:(char *)in and outputFromApp:(char *)out in EtermHandle
class, so that you can get outputs from the program and provide inputs
to the program. Of couse, how to parse the outputs depends on what the
program does and it's up to the programmer to implement them. Some
basic framework are also there, such as the routine to set up the
DEFAULT.
There is no general mechanism to change the underlying program
during program execution. It is believed that anyone uses this toolkit
intends to rewrite the toolkit to serve specific program. It is
therefore not necessary to change the program from time to time. The
CSH program included is merely an example. No optimization to the
speed nor elegancy to the interface has been done.
Usage:
1. Programmer must create a subclass of HandleDeputy which implements
inputToApp:(char *)in and outputToApp:(char *)out. This class can but
not necessarily implement the output parser. inputToApp:(char *)in is
supposed to be called in the program whenever you need to provide
inputs to the program. outputFromApp:(char *)out will be called if
there are outputs from the program. Calling is automatically and the
ouput parser can be called from this program. Appender class can serve
as an example about how these two routines can be implemented.
2. The default framework is in BlackHand class. You might want to
change them if you need any default value to be set.
3. To change the program you want to interface with. Change the
AppsName and ProgName in BlackHand.h. AppsName is the name of the
front end. In addition, you also need to change Csh_main.m, Csh.nib,
Csh.iconheader to AppsName_main.m, AppsName.nib and
AppsName.iconheader and the corresponding file name in IB.proj.
ProgName is the name of underlying program. It must be a full path
file name. Instead of "csh", you should specify it as "/bin/csh".
Acknowledgement:
This toolkit is basically modifications of Emacs by John G. Myers.
Some class names have been renamed to reflect what they do. Some,
however, have the same name as in the original source code.
The codes to create the pty/tty pair, setup the terminal and fork
and spawn the program comes from the emacs distribution.
This toolkit carries the same copy right as in Emacs 2.0. Please
see copying.rtf for further information.
Chin Hsiang Wu
chin@sg1.chem.upenn.edu
P.S. If you find any bug in this toolkit, please let me know and I
will try to debug. If you think the explanation above is not clear
enough and you can do a better job explaning. Do whatever modification
is necessary. Send me a copy of your modification if you want to, but
not required.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.