Roman Budzianowski 6/15/91 Internal Project Athena MIT report - not for distribution Eureka! System for Visual Programming of Educational Applications The idea of visual programming has been around for a while(thinklab). The ultimate goal is to enable non-programmers to create applications. Attempts to design such systems had limited success. Very popular area of intensive research related to visual programming are user interfaces. UIMS - user interface management systems - are in fact visual programming systems limited to one domain of programming. The most ambitious ones allow users to create new interaction techniques - e.g. Peridot. Others require users to choose one of the preprogrammed interaction techniques. All assume that the semantic part - the application - is hand coded. This system is designed specifically for the university environment. The audience are professors and students. Our goal is to enable professors to create applications - both user interface and the semantic part - in an interactive, visual way. In this aspect it is a very ambitious goal. On the other hand we are very modest in our design in that we assume that all interaction techniques and all semantic concepts are predefined and preprogrammed in the system. We rely here on unbounded creativity of the students, employed to extend the system. 1.Architecture -------------- The system is written primarily in C++; The system uses the Object Oriented technology. The system is a visually oriented interpreter. In the future it may be extended to include a form of compilation. The system serves as a UIMS, allowing users to create user interfaces. The technology employed here is the X Window/ Xt Toolkit package. The interactions are built out of a set of predefined widgets, e.g. Athena or Motif. Adding new widgets is very easy: by writing a simple C++ wrapper and linking in the object file consisting of the wrapper code and the widget C code. In the future we may extend the system to include dynamic linking. The semantic part of the system is geared primarilly to simulation type of applications in the fields of: mathematics, physics and engineering. Running application is a network of objects communicating with each other through messages and callbacks (direct connections). The application designer graphically creates objects and sets the communication network. There are four types of objects: graphical objects, semantic objects (operations), active values and messages. 2. Graphical Objects -------------------- The graphical objects are Xt widgets wrapped in C++ classes. The graphical objects can be edited (i.e their X resources), they have one or more inputs and/or outputs and accept messages. 3. Operations ------------- The operation can be as simple as adding numbers or as complicated as a Runge-Kutta algorithm for numerical integration. A number of operations is predefined. New operation can be added by hand coding in C++ using an API. Operations available in the system (including extensions) can be graphically grouped to create more complex operations. Complex operations can be saved for reuse. In the future those complex operations will be compiled for efficiency. Operations have inputs and ouputs. 3.1. Basic operations --------------------- - add, subtract, multiply, devide, negation - matrix operations - all 16 logical operations - logical "amplifier" - counter - "editable" state machine - other The above operations allow for simple flow control. 4. Active values ---------------- Active values are means of maintaining and changing the state of the running application. Active values accept messages: retrieveValue, setValue and getValue. Upon recieving the retrieveValue message the active value prompts the user for the new value. The same mechanism is used to set an initial value. Upon receiving the setValue and getValue messages the active value notifies interested objects if a treshold or delta conditions are satisfied. 4.1 Predefined active values ---------------------------- - integer - floating point number - vector - array - boolean - list 5. Factory objects ------------------ Factory objects accept create message. This are objects that provide the capability to create objects of predefined type: graphical objects, operations and active values. 6. Messages ----------- Messages are means of communication between graphical objects, operations and active values. Objects can communicate also through callbacks. There is a predefined set of messages that builtin objects understand : - edit for all objects - map, unmap for graphical objects - newValue for graphical objects and operations - retrieveValue, setValue and getValue for active values - create for factory objects 7. Saving --------- Users can save the state of the system into a file and restart from the same point. There is no clear distinction between editing (development) phase and run phase.