UI Overview: 3 Using the Generic Classes

Most of your application's UI needs will be satisfied by the use of generic UI objects. Many applications may need only the generic classes. Generic UI objects are powerful and easy to use, and they provide a number of services normally left up to application code.

Generic object classes have no inherent visual representation. Rather, each generic object represents a certain set of UI functions instead of UI components. For example, the GenInteraction class implements grouping and organizational functions; it can appear in several forms including menus and dialog boxes. It can also have no visual representation but merely provide geometry management for other generic objects.

What visual form a generic object takes, if any, is determined by two factors: the specific UI library in use, and the instance data of the generic object.

A specific UI library is essentially a "UI driver" that translates the generic class into its specific representation. Just as each video card has its own driver, each UI specification (e.g. OSF/Motif or Presentation Manager) has its own specific UI library. This library uses the generic object's instance data to determine the exact form of that object's output and input. A GenValue object, for example, may be implemented as a spinner object in one specific UI but as a slider object in another.

The generic object's instance data determines the features of the object as implemented by the specific UI. Across different GUI specifications, each similar object may appear different or handle input differently. For example, a button in one GUI may invert itself when pressed while the same button in another GUI might simply darken its outline when pressed. However, both buttons will do the same task. Therefore, a generic object's instance data must be categorized into two types: Attributes are instance data that will cause the same results no matter what GUI is used (e.g. the function the button performs). Hints are instance data that suggest particular implementations that may or may not be implemented by the GUI in use.

The way the generic object gets translated by GEOS into a visible representation is a complicated process. All generic classes are subclasses of GenClass , which is defined as a variant class. This means that GenClass has no defined superclass, that the superclass can be changed from time to time. The superclass is determined when the object is instantiated and resolved--when its visual representation is called for. (See the GEOS Programming chapter.)

The specific UI library contains objects subclassed off VisClass . These objects know how to handle input events and have very specific representation on the screen. These specific UI classes connect to the generic classes through the master/variant mechanism; in this way, the superclass of a generic object is assigned to one of the classes in the specific UI library. The generic object thus inherits the specific class' visible representation.

The above process happens entirely at run-time. The application does not have to have any knowledge of which particular GUI is in use; the same application executable code will work with any specific UI library. Because of the generic UI of GEOS, a user can run the same application under several look-and-feel specifications; this is desirable to the programmer because he only has to code the application once to receive the benefits of several different GUIs.

The Generic Class Tree

Creating a Generic Object Tree

GEOS SDK TechDocs |

2 The GEOS User Interface | Next:

4 Using the Visible Classes