This chapter explaines important data types, functions, and the program structure of the graphical user interface. Definitions and data structures used by the program, are located not only in the file glob_typ.h of the SNNS kernel, but also in the header files of the X-window system and the Athena Toolkit. For reference of those definitions see the X11 documentation release 4.0 or 5.0.
How X, XGUI and the kernel cooperate is sketched in
figure 
. The MIT Athena Toolkit was selected
because of its widespread use. In this toolkit, so called
widgets are defined (window elements like boxes, menu buttons,
toggles, scrollbars and so forth). XGUI should work with all window
mangers, but the following descriptions refer only to the twm
window manager.
Figure: How X, XGUI and the simulator kernel cooperate
After opening of the first window, SNNS-XGUI transfers control to X by
entering the main-event-dispatch-loop
.To react to different events (e.g. mouse
movement), X now calls predefined subroutines like callbacks and
event handlers, which return control to X after completion. All outputs
(e.g. line drawing) are buffered by the X server until it has resumed
control. This asynchronous behaviour complicates debugging, since
changes in the user interface are invisible at the time they are
processed. The compile switch DEBUG forces the X server with
calls to XFLUSH() to produce output at crucial points. The same
result is obtained by specifying -synchronous as an argument in
the call to XGUI. In both cases output speed decreases dramatically.
For windows which return a value, like the Layer window or the Confirmer, X must react directly to events. There, the Event-Dispatch-Loop is re-programmed where the exit condition is true after the call to a routine for a specific button (e.g. DONE). The next program segment can immediately use the result. The call to the confirmer demonstrates this very clearly:
if (ui_confirmYes(''Load will erase current network. Load?''))
ui_file_loadNet(filename);
else
ui_printMessage(''Loading aborted.'');
...
ui_confirmYes() builds the confirmer and dispatches all events until one of the buttons YES or NO is pressed. Then it returns this value as a boolean. Without this loop, the confirmer would become visible only after the processing of the code, and a default value would always be returned!
On processing the teaching cycles or the update steps, it is necessary to check for new events after each step. This is the only way to recognize the clicking of the STOP button in time. The WorkProc construct is a means for solving this problem. The routine for performing one step is declared as WorkProc with the statement XtAppAddWorkProc(...). This routine is called as long as no events are waiting. When all cycles/steps are processed it returns True, thereby being removed. A soon as the button STOP is pressed, the corresponding callback routine ui_rem_stopProc removes the WorkProc with the command XtRemoveWorkProc(ui_workProcId). A WorkProc, already existing when a new one is defined, gets deleted (see also [You89], p. 136ff). This also explains, why the starting of update steps cancels a running teaching process and vice versa. A running WorkProc always terminates correctly, i.e. it is not interrupted by incomming events. Therefore XGUI processes all events as usual, but slows down with increasing running time of the WorkProcs.
In general there is one callback function for each button. However, some buttons call the same function, and use just different values for the argument client_data. This argument, the calling widget and an aditional argument call_data are passed over to the callback procedure. client_data is defined by AtAddCallback(), call_data by the kind of widget that is calling. The scrollbar widget, for example, passes the position of the slider.
With the use of window systems like X, a structuring of the source
code according to the windows used is almost automatic (see also
table and ).
Table: The source files of SNNS-XGUI, Part I
Table: The source files of SNNS-XGUI, Part II
Callback procedures are kept in a separate file. Since SNNS-XGUI consists mainly of those functions and calling depth remains fairly shallow, the source code is easily readable.