Abstract DIGIS (Direct Interactive Generation of Interactive Systems) is a graphical UI design environment for non‐programmers that facilitates the design of all aspects of a UI with direct manipulation techniques. DIGIS is based on four models: an object model, a system task model, an interaction model and a dialogue control model. These four models describe an interactive system at a high conceptual level which allows a UI designer to quickly construct a high quality direct manipulation UI that supports undo‐redo, context‐sensitive help and guidance, and connect the UI with the (existing) application.

Abstract DIGIS is a design and implementation system for developers of general purpose interactive applications (IA). It is itself an interactive system that accomplishes its task by Direct Manipulation techniques, in principle without using a programming language. DIGIS is a generator in the form of a window‐based workbench. It has two input sources. One is a toolkit of predetined interaction tools consisting of prototypes and instances. The other is the set of predetined application procedures thai make up the application part of the IA. The application procedures do not handle user input but may handle textual or graphical screen output. The task of the developer is to build the user interface by selecting the appropriate interaction tools. tailor them to the interface, and tie them to application procedures. This includes the visual representations of interaction tools, their prompts, echoes and feedback. In the process he maps user input to parameter lists for the application procedures, and return parameters to interface output. DIGIS will also support the detinition of composite input (interaction patterns such as sequences). Unix and X are the initiat operating environment, adaption of the input sources to PCTE. OSF/Motif, and Open Look is feasible and anticipated. The design of DIGIS is based on a hierarchical interaction model that is the second focus of this paper. The implementation will be done using PROCOL, a locally developed concurrent object‐oriented language. which offers protocols that support composite input. The language is a superset of C, and therefore fully compatible with existing C libraries. ACM Categories and Subject Descriptors: D.2.2 [Software Engineering]: Tools and Techniques ‐user interfaces, programmer workbench; D.3.3 [Programming Language]: Language Constructs ‐input/output, programming structures; H.1.2 [Models and Principles]: User/Machine Systems ‐human factors; 1.3.6 [Computer Graphics]: Methodology and Techniques ‐ interaction techniques, ergonomics, languages:

PROCOL is a parallel C-based object-oriented language with communication based on one-way synchronous messages. Objects execute in parallel unless engaged in communication. Communication partners are defined by object instance identifiers, or by type. Therefore send-receive mappings may be 1-1, n-1, or 1-n, though only 1 message is transferred. PROCOL controls object access by a novel concept: an explicit per-object protocol. This protocol is a specification of the occurrence and sequencing of the communication between the object and its partners. Thus protocols support structured, safer and potentially verifiable information exchange between objects. Protocols also act as a composition rule over client objects, thereby offering a 'part-of' hierarchy of these cooperating objects.

A language model is presented for the specification of User Interface Management Systems. The model, called the Abstract Interaction Tool (AIT) model, offers a tree-like hierarchy of interaction objects. Each object represents a subtree and can be considered as an abstract input device containing a syntax-like specification of the required input pattern. The hierarchy of specifications amounts to a system of syntactical productions with multiple control. Terminal nodes of the AIT tree represent the interface to the physical interaction devices. The AIT model features hierarchical output resource management. At the higher, more abstract, level the input-output is loosely coupled. At lower levels the coupling becomes increasingly tight. At the upper levels, AITs model the functions (what) required by the user, whereas at the lower levels the way to accomplish them (how) is stressed. The AIT model has modes for multithread and multiple-device user interaction. There are facilities for context-dependent prompting, echoing, feedback, error correction, and expertise levels. A special section in the AIT provides for links to application modules. As a model for general interactive systems, AITs can be applied to graphics, process control, dialogue, and real-time systems. AITs can also be used to define controlled production rules in knowledge-based systems. In addition the model can provide tools for the software engineering phases specification and prototyping.

To exploit the full capabilities of raster graphics, two and three dimensional drawing primitives should play a preponderant role in the specification of a graphics standard. In addition there should be facilities for modeling and hierarchy. HIRASP presents an integrated language system fulfilling these requirements. The pattern is used as the basic drawing primitive. It consists of a colour function defined over an arbitrary OD to 3D domain. There are a number of basic pattern primitives. Arbitrarily complex patterns may be composed from pattern expressions. But once an expression is assigned to a pattern, the constituent structure loses its existence. Patterns define the static structure of HIRASP. On top of this a dynamic structure is built to allow for interactive modification. This dynamic structure can be represented as a directed graph, the so-called pattern graph. Patterns are the leaves of this graph. Each node carries a set of alterable orthogonal attributes, controlling domain and colour transformations, highlighting, visibility, detectability, level, and transparency, for the subgraphs descending from the node. The interpretation (traversal) of the graph results in a 2 1/2D mapping, akin to the Painters algorithm, or a full 3D mapping, on a graphics screen.

Abstract An extended model and calculus, called RasterCalc, is presented for operations on discrete graphics rasters, including their colour functions. The operations are separated into two main categories: operations on domains, and operations on colour functions. The operations are further classified as local and remote, depending on the correspondence between destination and source pixels. The new raster element or pixel can be a function of a single element from one or more rasters, a function of a small area from other rasters, or a function of entire rasters. Local operations have their main applications in computer graphics, while remote operations are more oriented towards image processing. A mathematically oriented notation is used to define and represent the operations included. RasterCalc has been implemented as a procedure package in Pascal, to be used on a powerful, yet expensive display. Recently a C version has been completed for a personal colour computer with a special chip for raster operations. The work reported in this paper is partially supplied by the Dutch Technical Sciences Foundation, under project number LWI 14.0130: “Facilities for raster graphics in programming languages”

Abstract IDECAP is a database type information system. It is different from regular database systems as the information is mainly presented via thematic maps displayed on a graphics screen. Retrieval of information is usually achieved by means of graphical interaction with these images. The system utilizes interaction techniques and systems software from interactive computer graphics, using vector graphic and colour raster graphic stations for output. The present databank contains data based on grids and polygonal data. The system is being applied, but not restricted, to the Dutch 1971 Census data and the 1978 land use data. It allows the mapping of grid variables against a topographic background. Areas of interest can be investigated in detail by zooming in on a window drawn on the graphics screen by the user. Maps can be adjusted by user‐definable class distributions shown in the form of histograms with standard deviations.

A conceptual model is discussed which allows the hierarchic definition of high-level input driven objects, called input-output tools, from any set of basic input primitives. An input-output tool is defined as a named object. Its most important elements are the input rule, output rule, internal tool definitions, and a tool body consisting of executable statements. The input rule contains an expression with tool designators as operands and with operators allowing for sequencing, selection, interleaving, and repetition. Input rules are similar in appearance to production rules in grammars. The input expression specifies one or more input sequences, or input patterns, in terms of tool designators. An input parser tries, at run-time, to match (physical) input tokens against active input sequences. If a match between an input token and a tool designator is found, the corresponding tool body is executed, and the output is generated according to specifications in the tool body. The control structures in the input expression allow a variety of input patterns from any number of sources. Tool definitions may occur in-line or be stored in a library. All tools are ultimately encompassed in one tool representing the program.

InputInput tools, originally introduced as a language model for interactive systems and based on high-level, input-driven objects, have been developed into a model for communicating parallel processes, called the input tool process model (ITP).In this model every process contains an input rule, comparable to the right-hand side of a production rule.This rule specifies in an expression the patterns and sources of input it exPects and where the input is to be handled.The reception of the input triggers action inside the too! process.As part of the action, messages may be sent to other processes, with destination specified to a varying degree of identification.A potential candidate for a message is any tool process with the correct type of message slot.Because sending tool processes do not have to specify completely the identity of receiving tool processes, and vice versa, ITP provides a fully dynamic communication model.Most communication aspects of other recently developed models are contained in this model.Synchronization of processes is accomplished implicitly by the input specification; explicit synchro-nizatiQn constructs such as monitors and guarded regions can therefore be easily simulated.The ITP constructs provide a general concept for interprocess communication.Its application areas range from interaction via process control to operating systems.From a programming point of view, the language constructs offered are not in any way dependent on whether processes run on single or multiple processors.

A proposal is made for the definition of 'tools', high-level graphics input functions based on the six primitive input classes Clock, Pick, Button, Key, Valuator and Locator.

GPGS is a subroutine package offering powerful and versatile support for passive and interactive vector graphics, for time-sharing, batch, and stand-alone minicomputer systems. The package is computer, language, and operating system, as well as display device independent. Its key purpose is to allow for transportabiliit of programs and programmers by providing easy to learn, high level features. The applications programmer writes his program once and then executes it on any supported graphics equipment without recompiling or relinking it. Device-independence was implemented by dividing GPGS into a device-independent part invoked by the applications programmer, and internal, "device drivers", one per display device. Like the GSPC "Core System" whose design it influenced, GPGS is a general purpose package. It has a subset of graphics facilities to handle output of line and character primitives with attributes such as line style and character size, and input from interaction tools such as lightpens, keyboards, valuators, and function keys. It also supports 2D and 3D viewin transformationss for clipping and window to viewport mapping, and coordinate transformations.Unlike the GSPC Core System, GPGS also includes a set of basic features for modelling objects which allows definition of device independent masters called seudo picture segment. These are distinguished from normal, device (DPU) dependent pictur segments into which primitives and their attribute-value settings are ordinarily compiled. These masters may be instanced subject to affine transformations (translate, rotate, and scale) to create a typical master-instance hierarchy. The hierarchy may be stored in a disk based library or compiled into a normal picture segment for output to a display device.The images of objects stored in device dependent picture segments may be transformed on the display surface by v port (image) transformations. These typically allow use of hardware transformation capabilities for dragging or tumbling object images.Host/satellite graphics is accommodated by having the device independent part of GPGS in the host and splitting the device drivers across host and satellite. At the source code level it therefore makes no difference on which.configuration a program will be executed.Among the existing implementations are versions written in assembler for the IB 360/370 and the PDP 11, in both stand-alone and satellite mode, and under a variety of operating systems. They support plotters, storage tubes, and high performance refresh displays. FORTRAN based implementations exist for the Univac 1108, the PDP 10, and a Harris minicomputer.

Abstract COMLNK is a software system designed to provide the user of a communication link between two processors with facilities for file transport and Job submission from one computer to another. It has been implemented for a high speed communication link between an IBM 360/370 running under OS/MFT, MVT VS1 or VS2 and a PDP 11 running under DOS. The various record formats which are supported by the operating systems for their file organizations can be handled in a straightforward manner, while conversion options from one format to another are possible. Files may be shipped, listed on the IBM printer, punched on the IBM punch or submitted to the jobqueue.