PIGS is intended to help people write interactive graphics programs without requiring them to become systems programmers. PIGS organises the command flow from an operator to an interactive graphics application program and helps a programmer structure that application.
When the application is being used, the PIGS Run Time Environment (PRTE) presents a standard display layout to the operator with a list of his current choice of commands (the current menu), reads commands from one of several input devices, enters an application procedure associated with that command and presents to the operator a new menu on the display if required. When the application is being designed, the programmer provides a text description of each command and the organisation of commands into menus. This description (the MDL file or menu definition) is assembled to produce a binary discfile (Menu Binary or MNB file) containing all information about each command and menu.
The command structure can be easily reorganised; new commands and menus can be added at run-time.
An interactive graphics program allows an operator to specify a series of actions that he requires the computer to perform on his data. As a result of some actions an altered image appears on the display device. Each new image, since it tells (or should tell) the operator something he didn't know before, will certainly affect and hopefully guide the subsequent commands he makes to the program. In addition a well-written interactive graphics program shows the user his choices at each stage. This is in contrast to a batch program where the user summons a well-defined algorithm and receives the solution only when the algorithm halts. Thus interactive graphics programs are extremely valuable in problem situations where no explicit solution algorithm is known, but a set of helpful procedures is available. These procedures are selected and linked together by the actions of an operator/user.
In writing an interactive graphics program there are 3 problems which PIGS attempts to solve:
PIGS is an attempt to address these three problems. Figure 1 illustrates its relationship to the component parts of the system. PIGS itself is represented by the 2 boxes in the figure, which correspond to the 2 phases: design (MENDEL) and operation (PRTE) of an application program.
It aids logical explanation to separate PIGS into these 2 phases even though:
PIGS was designed to run. on the PDP15/40 using DOS (Disc Operating System) and takes advantage of the fact that the hardware and software are more substantial than that of a basic minicomputer. Nonetheless, satellite computers are becoming more powerful and the number of computers for which the ideas of PIGS are suitable, is increasing. The hardware and software environment includes:
Figure 2 shows the standard layout on the refreshed display used by a PIGS Graphics Application Program (GAP). This display is generated by the PIGS Run Time Environment (PRTE). The largest area, the Main Display-Area, is-not used by PIGS and is therefore free for the GAP to use. Moving clockwise, the 2 message areas can be used by both PIGS and the GAP via subroutines. Messages output to the error area blinks and cause the teletype bell to ring. Application programmers are encouraged to insert messages in the prompting area to guide the operator. The top right corner shows the menu name and exit command for the current menu. Below is a list of commands (or lightbuttons) which constitute the current menu. These choices are local in that they will disappear when a new menu is activated. Each command consists of a text string followed by an optional data display area. The GAP can alter the data areas using subroutines. Below the display area are 6 pushbuttons. These can be pressed to activate up to 6 local commands, whose names appear as prompts and also as lightbuttons. Above the pushbutton prompt, operator typing is echoed (the VT04 console keyboard is read-only). Any command typed on the keyboard is echoed here. The subroutine which reads keyboards and echoes typing is available to the GAP. Above the keyboard display area are 6 global lightbuttons; these survive menu changes and may be selected regardless of the current menu. The complete set of global commands includes the global lightbuttons and other globals which are not displayed and which therefore can only be keyed in or scheduled.
To discuss commands it is useful to trace the flow of control through PIGS as it processes a command. This is illustrated in Figure 3. The word required in this figure refers to a choice which the application programmer makes when he constructs the menu-definition (Section 6). The dotted arrows refer to the deferred argument capability (Section 5.3) which is not currently available in PIGS.
Assume a menu is displayed as in Figure 2, and that PIGS is waiting for a command. Four command sources are polled for a command from the user. These are the keyboard, lightbuttons, pushbuttons and the clock.
Two keyboards are available to PIGS, one produces hardcopy and the other doesn't. Only one keyboard is active at a time. The syntax of a keyboard command is described in section 5.3. An operator selects a lightbutton by picking one of the displayed command text-strings with a stylus device (the sparkpen/writing tablet or the lightpen). A tracking dot on the display follows the sparkpen; a lightbutton is picked if the operator depresses the pen when the dot is coincident with the lightbutton. Pushbutton commands (PENAC or ACCEP in figure 2) are entered by pressing one of the 6 buttons. Clock-initiated commands (any global or current local) can be scheduled at regular intervals for a fixed number of occurrences. For instance the application programmer can ensure that the database is regularly dumped. A scheduled command will only be initiated during polling.
When a command is entered, the lightbutton may blink for a set delay as a visual confirmation to the operator and to prevent inadvertent multiple hits. The application designer can instead indicate that the command be executed immediately, if suitable for the command; such a command might be rotate selected object by a preset amount.
Any PIGS device may be used for input by the application procedures using subroutines provided.
The most general form of command which PIGS accepts is the keyboard command. Keyboard input is free format and consists of a command name followed by arguments separated by commas. An argument can be a string, a number, an array (not implemented currently), omitted or deferred (not implemented currently).
A string is entered simply as a sequence of characters unquoted or, if ambiguity is possible, enclosed in quotes. A command name is syntactically the same as a string. A number can be integer (decimal or octal) or floating point. For instance the following command line has one omitted argument, two numerical (# indicates octal) and one string argument:
POSITION,, 123.45^+3,#62,"# 62" <cr>
If PIGS receives the typed command,
SETPT,*,512 <cr>
it recognises that * is a deferred argument. It saves the current menu and displays a special menu of commands which retrieves arguments. This argument-getting menu might include commands to select an x-coordinate with a stylus, to read a typed string or to implement some of the standard lightpen techniques for inputting numbers (for instance thermometers or dials).
Whatever the command source, PIGS reconciles the command and arguments to a standard form. For instance if the PLAYB command (which, say, is preset to expect 2 arguments) had been entered by hitting a lightbutton, PIGS would proceed as if
PLAYB,*,*<cr>
had been entered on the teletype.
After determining that all arguments have been specified, PIGS looks up the command name in a command table produced by the menu-definition. This table gives the location of an application procedure to be executed whenever that command is received. The procedure is part of the application and must be a FORTRAN or assembly language subroutine without formal arguments. Application procedures retrieve arguments from PIGS using a set of standard subroutines. The procedure does not need to know which device was the command source, but it can find out if this is useful.
The procedure could also be defined in other ways, for instance as a saved list of other commands. This would be suitable for an operator who wants to define as a macro a sequence of commands that are frequently used.
On return from the procedure, PIGS again examines the command table to see if a new menu is to be placed on the screen. If so, a command table for the specified new menu is read from disc, where the menu-definition assembler (MENDEL) placed it, and PIGS waits for a new command with a new set of local lightbuttons on the display.
The new command table overwrites the old when read into core. The application programmer can specify that the old command table be written to disc first in order to save changeable information like display data areas.
An exit procedure for the old menu and an entry procedure for the new are executed if required. In general, these simplify protection and book-keeping for each program state.
Note that the method of swapping menus does not necessarily imply a hierarchic ordering of menus. Unlike subroutines once a menu has been entered, PIGS itself has no memory of which menu was previously active. Thus there is no implied return to a calling menu. A return must be effected by an explicit call. An application programmer must ensure that entry and exit procedures for a menu are meaningful for all possible previous and next menus, respectively.
In designing a new interactive graphics program using PIGS, the application programmer needs to decide what commands are to be provided for the operator, write a procedure for each and write a file containing a menu-definition to organise the commands. The menu-definition must then, using the MENDEL program, be assembled to produce a series of command tables in a random access binary disc file (the MDB file) and a jump-address-table which relates each command in the application to the starting address of a procedure; the loader generates the correct absolute starting address. The application programmer then creates an executable overlay file which includes PIGS run-time subroutines, the application procedures and the jump-address-table.
Part of a sample menu-definition is shown in figure 4; this is part of a file input to MENDEL. Each line (apart from comments) starts with a keyword followed by commas and arguments, using the same syntax as described for PRTE in section 5.3. Procedure names are indicated here as SUB1, SUB2, etc, but could be any legal assembly language or FORTRAN symbol.
PART OF A SAMPLE MENU-DEFINITION
/
/MENDEL FILE FOR FONTS PROGRAM
/COMMENTS PRECEDED BY 'I'
CREAT, FONTS, 15, 60, 0 /ALLOW FOR 15 MENU'S, 60 SUBROUTINES
KEYB, LTA /SPECIFY KEYBOARD
STYLS, VWA /SPECIFY WRITING TABLET AS COMMAND STYLUS
DELAY, 200 /LIGHTBUTTON BLINKS BEFORE EXECUTING
/MUST DECLARE MENU NAMES AND FORTRAN SUBROUTINES
MNDEC, CONTROL, DEFINFRAM, BOROERFRA, CONSTRFRA, .....
SBDEC, SUB1, SUB2, .....
/
/GLOBALS IF REQUIRED
.
.
.
/NOW DEFINE MENUS
/'COM' DECLARES COMMAND NAME AND NUMBER OF ARGUMENTS
/ DO, SUBROUTINE NAME SPECIFIES THE SUBROUTINE TO BE OBEYED
/ AFTER THE LIGHTBUTTON BLINKS
/ GO, MENU-NAME SPECIFIES A NEW MENU TO BE PRESENTED
/ TO THE END-USER
/MENU 'CONTROL' IS DISPLAYED FIRST ON ENTRY
/AND PRESENTS THE END-USER WITH A CHOICE OF SUBPROGRAMS
MENU, CONTROL
.
.
.
COM, DEFINFRAM, 0,,, GO, DEFINFRAM
COM, PLOTFRAME,0,,, GO, PLOTFRAME
COM, OUTFONT, 0,,, GO, OUTFONT
/NOW DEFINE MENU TO SET UP FRAME INITIALLY
MENU, DEFINFRAM
COM, BORDERTYP, 0,,, G0, BORDERFRA
COM, FONTNUMB, 1, DO, SUB1.., 'NONE'
COM, CONTINUE, 0, DO, SUB2, GO, CONTSTRFRA
/NOW DEFINE MENU TO DO BORDER
MENU, BORDERFRA
COM, MM16,, DO, SUB3, GO, DEFINFRAM
COM, MM35SINGL,, DO, SUB4, GO, DEFINFRAM
COM, MM35DOUBL,, DO, SUBS, GO, DEFINFRAM
COM, NONE,,,, GO, DEFINFRAM
The application programmer may specify in the MENDEL program such PRTE options as whether the display is to have large or small characters, how long the lightbuttons are to blink for (section 5.2) and which stylus and keyboard are to be active initially. He must describe each menu to be included in detail.
Concerning each menu, the programmer must decide whether it should have entry and exit procedures (section 5.5) and whether pushbuttons should activate any of the local commands. He must also describe each command to be included in the local command display area.
Each command is declared in the menu-definition with a keyword COM. For each command, the programmer must specify:
Assembly of the menu definition file by MENDEL is a simple two-pass operation. It is extremely easy to alter most of the decisions initially made about the command structure - to regroup commands, for instance. All that need be done is to use the DOS text editor to alter the menu-definition, reassemble it and load the overlay file again with the new MNB file on disc. It is not necessary to reconstruct the overlay file (a more lengthy process) unless application procedures are to be added or edited.
In section 2, a fairly rigid distinction was made between the 2 phases in which PIGS operates (MENDEL and PRTE). In fact it is possible for an operator to modify the GAP design at run-time if the application programmer allows certain internal PIGS routines to be summoned explicitly by command. In this way the operator can alter the MNB disc file at run-time to add new commands (provided no new application procedures are necessary), or alter the arrangement of commands in a menu.
To avoid limiting the experienced package designer, the routines composing PIGS have been coded and documented for library usage and it is hoped that a designer can arrange to take control from PIGS and return it easily. There is a subroutine NMNU, for instance, which immediately changes to the specified menu and returns control to PIGS. Similarly, the polling routine can be run by a package procedure. Thus, a clever designer should be able to grab control from PIGS for elaborate interaction and return control when through.
PIGS does not cover all aspects of interactive control. A principal consideration in designing it has been to offer a useful interaction structure for novice package designers without needlessly limiting more experienced programming.
A first version of PIGS has now been implemented. With the small amount of experience gained so far, a few comments can be made.
This appendix lists some terms that are used in PIGS and refers to a section where they are explained.
The work referred to in 1,2 and 3, below, addresses similar problems in interactive graphics. PIGS was influenced to some extent by the system of Butlin (Ref.2) but differs in design philosophy and because of different hardware and software configurations.
1 Boehm "POGO - Programmer-oriented Graphics Operation" (1969. AFIPS Vol.34 pp 321-330)
2. Butlin, G.A. "A FORTRAN package for interactive graphics" (1970. Advanced Computer Graphics3 (ed) Parslow and Green. pp 947-965)
3. Cotton, I.W. "Languages for attention handling" (1970. Advanced Computer Graphics3 (ed) Parslow and Green. pp 1049-1091)
4. Shaw, W.D. PIGS Manual (1974. SRC Atlas Computer Laboratory)
5. Shaw, W.D. PIGS - PDPI5 Interactive Graphics (1973. DECUS EUROPE Ninth Seminar Proceedings. pp 299-301)