Forth, metaWINDOW and GUI design

Abstract

ELUS by Eleusinian Enterprises is discussed as an example of a mixed language Forth implementation which include~ its own GUI toolkit, the Interactive Screen Designer. The linked Meta WINDOW graphics library (Meta graphics Software Corporation), makes the design and implementation of graphics application user interfaces possible, intuitive, and efficient. The discussed utilities of the Interactive Screen Designer include the design of standard window and control screen objects, paint facilities for creating customdesigned application windows, and a Linker utility which allows any predefined screen region to be linked to executable code. A music application, ELUS:TD, and an ELUS music utility, SETMATRIX, are demonstrated as examples of virtual device panels and control interfaces created with the Interactive Screen Designer. INTRODUCTION The purpose of this document is to describe the Interactive Screen Designer, a Graphics User Interface toolkit which is included as a standard feature of ELUS, a Forth based Music Applications Development Environment. Eleusinian Enterprises is involved in the development of music software targeted at the commercial and experimental markets. Forth was chosen for the development environment because of its many exceptional and superior features. However, very early on it became clear that a traditional Forth system also had a number of significant drawbacks with respect to the development of commercially oriented applications. In particular, no Forth system known a~ that time included support for the development of a Graphics User Interface. In view of the many music applications which have been introduced with GUis, it is all too obvious that the development of a GUI for end user applications was and still is mandatory in order to penetrate the market with a Forth developed application. ELUS was developed to address this lack of GUI support in a Forth based system. as well as to address a variety of other needs. Although ELUS is still under development, a discussion of the current implementation of the Interactive Screen Designer, the ELUS GUI toolkit, will provide a sufficiently informative overview of the graphics capability of the system. MIXED LANGUAGE IMPLEMENTATION ELUS is a mixed language Forth implementation. Currently, two C language external libraries are linked to the Forth kernel: MetaWINDOW by Metagraphics Software Corporation is a graphics library which provides device independent graphics programming; and Baby Driver by Autumn Hill Software, Incorporated, is a table driven printer library. Two layers of code were implemented in order to make these C libraries function with the Forth environment First, an assembly language interface routine was developed for each library; the functions of the. interface routines are to locate the external libraries and to preserve the state of the system stack. Second, high level Forth routines were implemented to compile references to the external libraries and to bring the C calling conventions into conformity with standard Forth stack usage; these high level This paper was presented at the Fourth Annual SIGEorth Workshop, held in Kansas City, MO, March 5-7, 1992, and published in the SIGForth Newsletter, Vol.4 No.4, December 1994. P23 Forth routines took the form of defming words. Because these libraries are available only for DOS 80x86 machines, the resulting Forth implementation is not currently portable to other platforms. In addition, to hold down the price for end users, the royalty-free version of Meta WINDOW is used, but this version does not support the high resolution VGA configurations currently available; the highest resolutions supported in ELUS are 1280x800 monochrome and 640x480 16-color VGA. In return for the increased device dependency and limitations on supported VGA modes, the mixed language Forth implementation does provide a workable solution to the implementation of a Forth GUI toolkit. IHGH LEVEL INTERFACE TO META WINDOW Meta WINDOW Defining Words Each MetaWINDOW function is assigned to a function class which is determined by the stack effects. Each function class is implemented as a defining word. The name of each MetaWINDOW defming word begins with :MG , where MG stands for Meta Group, and ends with two numbers separated by a hyphen, the frrst number indicating the number of stack arguments before the function is called and the second indicating the number of stack arguments returned after the function is executed. The CREATE portions of all MetaWINDOW defming words are identical and consist of: creating a dictionary entry, and compiling the Meta WINDOW procedure ID into the parameter field of the child word. The DOES> portions of all Meta WINDOW defining words are analogous in function and consist of: stack setup (required for some), stack preservation, calling the MetaWINDOW function, and stack cleanup. Two assembler primitives are used for preserving the stack and calling the Meta WINDOW functions: @META-SP ( -n) must be executed prior to calling a MetaWINDOW function. "n" is the number of stack elements which the MetaWINDOW function expects. Note that this is always one more than the total number of input arguments as indicated in the stack comment for the DOES> code. The reason for this is that the MetaWINDOW function number is fetched from the parameter field address and placed on top of the stack just before the MetaWINDOW function is called. Since the placement of the appropriate function number on the stack is imbedded in the DOES> code, it is not reflected in the stack commentary. ( nl n2 ... nx BX -AX DX) is'the routine which executes the MetaWINDOW code. Since the MetaWINDOW functions are C language routines, they expect the stack arguments to be in the C calling sequence as documented in the Meta WINDOW Reference Manual, C Language Version. The function ~of the DOES> code prior to @MET A-SP is to reorder the stack to the C calling sequence. After the function has been executed, the system environment prior to the function call is restored, and the contents of the AX and DX registers are pushed to the stack. Depending on the function, one, both, or none of these return values are dropped. C Calling Sequence and Stack Setup Integer Value Parameters The C calling sequence for integer value parameters is opposite to that of Forth. In C, the arguments are pushed onto the stack in the reverse order in which they appear in the procedure's calling sequence. This means· that the last argument is frrst placed on the stack, proceeding from right to left. void MOVETO (X, Y) int X, Y; In this example, the procedure MOVETO expects on the stack the integer values of X andY, where X is placed on the stack after Y, and returns no values (void). In order to simplify the syntax of the high level user vocabulary and retain the convention of entering the'X-coordinate before the y-coordinate, it would be logical and desirable to hide the stac!C setup in the DOES> portion of a defining word. :MG2X-O CREATE n [proc-id]) DOES> n2[parm2] nl[parml]) -ROT SWAP ROT 3 @META-SP @ DDROP Then-a high level FORTH word is defined: 92 :MG2X-0 LINETO ( x y) where 92 is the Meta WINDOW procedure ID code for function LINETO. Executing