The ORIGIN specification informs the compiler, that this program is utilizing the guienv library. The '~beta/guienv/guienv' specifies that the BETA compiler is expected to find the fragment guienv on the disk in the subdirectory of the guienv directory, which is supposed to be located in the directory where the Mjølner System is located. Please also note that the guienv fragment must be located in the specified directory. If this is not the case, change the above directory specification.
If you want selectively to use some of the other Lidskjalv libraries (fields, control, scrollingList or figureItem), the libraries must be specified in INCLUDE clauses. E.g. to utilize both the fields and control libraries, the program must look like:
Note that the main part of a Lidskjalv application contains an inserted instance of the Guienv pattern (not to be confused with the Guienv library). This Guienv pattern is taking care of all event handling of events originating from the underlying window system (e.g. mouse button events, window refresh events, keyboard events, etc.) such that Lidskjalv application programmers does not have to be concerned with managing the global event loop. Each user interaction (e.g. menu selections) result in execution of some specific actions of some BETA objects (details later).
The declarations part of a Lidskjalv application contains declaration of patterns, objects, and declaration of specializations of user interface objects such as menus, windows, buttons, etc. Most of the functionality of Lidskjalv applications will in fact be specified in these specializations, since activation of most of the functionality will originate from the user manipulating items in the user interface.
The initializations part of a Lidskjalv application is primarily concerned with initialization of objects and with the creation and initialization of the various menus, windows, buttons, etc. The structure of Lidskjalv applications is such that the main part of the application is normally not concerned with invoking the functionality of the application, since that is usually the result of the user manipulating the user interface.
Events (e.g. window refresh events, mouse button events, keyboard events) must be taken care of by the Lidskjalv application some way or another. The approach taken is to handle the global event loop for the programmer. When specifying interface objects [1] in a Lidskjalv program, the underlying implementation takes care of propagating events to the appropriate interface object. Events, (e.g. mouse button) will be converted into invocation of virtual procedure patterns of interface objects. These virtual procedure patterns (e.g. onMouseDown and onRefresh), must be extended by the Lidskjalv application programmer to contain the proper response to the specific event. That is, interface objects define various virtual procedure patterns that specify the types of events that are relevant for this type of interface object . In Lidskjalv programs, the programmer creates specializations of interface objects with further bindings for the virtual procedure patterns with the proper response to those events. During the discussion of the various types of interface objects, we will be discussing more details of this event handling.
Lidskjalv applications will continue to be executing until the application explicitly specifies that it may be terminated. Termination of a Lidskjalv application is done by executing the Guienv attribute terminate when termination is wanted. The result hereof is that the global event handling is immediately terminated, resulting in the termination of the execution of the entire application.
| Lidskjalv: User Interface Framework - Tutorial | © 1995-2004 Mjølner Informatics |
[Modified: Wednesday June 6th 2001 at 22:13]
|