Event-driven Tasks and Graphical User Interfaces

Introduction

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. In GIPSY things have been made easier by allowing the user to specify inputs in advance at any moment, but the basic scheme is that the task determines what it expects and when it expects 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.

Events and event-handling

• The most primitive level only deals with file descriptors and timers. This level is described in the document events.dc3. For most application programmers only timers are interesting. Timers are described in ScheduleTimer.dc3. An example of their use can be found in events.dc3.
• The middle level deals with the Hermes-specific events. These are the events associated with user input keywords and one other event which is generated when a task is resumed after it was pausing. Almost every application programmer can ignore this level. It is described in herevents.dc3.
• The top level only deals with user input keywords. This is the most important level for application programmers. Documentation: keyevents.dc2.

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.

Graphical User Interfaces and Ggi

The following kinds of elements are available:

• Text fields
• Buttons
• Menus
• Analog valuators
• Text output fields
• Plot fields
• Canvasses

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 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.

Figure: example graphical user interface

Ggi mini-tutorial

1. A simple example showing the use of text fields, analog valuators and menus.
2. Identical to the previous example, except that the positioning of the elements is explicitly done by the program.
3. An illustration of the simple use of plot fields.
4. Identical to the previous example, except that cursor interaction has been added to the plot field.
5. Doing lengthy calculations.
6. Suppressing keyword events.
7. Plot fields, images and color maps
8. Plot field color map manipulation
9. Containers and pop-up shells
   General purpose pop-ups

Maintained by J. P. Terlouw