Event-driven tasks are fundamentally different from procedural tasks. A traditional procedural task, once it has been started, is always in control. It knows when input is expected and what the order of the different pieces of input is. From the beginning things have been made easier in GIPSY by allowing the user to specify inputs in advance at any moment, but the basic scheme was that the task determined what it expected and when it expected it.
An event-driven task, by contrast, is programmed so that it can handle any input at any moment. In this way the user, not the task, is in control.
In GIPSY a quite general way of event handling has been implemented, allowing the task to react to a limited set of different events, like the change of a keyword, the rejection of a keyword due to an error, the availablity of data on a file descriptor, etc.
Using this event handling, a collection of routines has been built, which allows the programmer to construct a graphical user interface for a task. Most of these routines are tightly coupled with user input keywords. In this way the user interface can be programmed and tested separately from the application code. Both components can then be integrated at a later time.
In order to accomplish this, quit() must have been registered (``scheduled'') by a call to ScheduleKeyevent(), specifying the function quit(), the keyword QUIT= and some other arguments. The last executable statement in an event-driven task is a call to MainLoop(), which usually does not return. MainLoop() receives all events and calls the functions which have been registered to handle these events.
When MainLoop() has been called, it is still possible that new event-handling functions are registered. This is then done from within other event handlers, e.g. as the result of some user action. Event handlers can also be de-registered, for keyword events for instance by calling DescheduleKeyevent().
It is also possible that there are more handlers for one keyword. In this case all handlers are called. The handler which was registered last, will be called first. Similarly one function can be registered more than once for different keywords. The function knows which keyword caused the event and can act accordingly.
The following kinds of elements are available:
A text output field is an element that can only display text.
A plot field is the Ggi-based implementation of a PGPLOT device. It has the same capabilities as GIPSY's X11 plot server, except that cursor interaction is implemented differently. An application can have multiple plot fields.
A text editor can be used to display and/or modify larger amounts of text, e.g. documentation, log files, directives, etc. It can work either on a text string in memory or on a file on disk.
A canvas is a simple element without any built-in behaviour. It can be used as a basic display window which must be manipulated using X library routines.
The elements in a graphical user interface can be positioned in two ways.
The easiest way is letting Ggi place them automatically. The elements
will then be put into one of three panes: the top pane will contain all
menus, the bottom pane all buttons and the middle pane all other elements.
This kind of placement is adequate for very simple interfaces and for testing.
It is also possible to position the elements explicitly. This can be done relative to the left and top edge of the task's main window or relative to the right and bottom edge of other elements.
|Maintained by J. P. Terlouw|