Volume 7A: XView Programming Manual

2

The XView Programmer’s Model

XView is intended to simplify application development under the X Window System by pro-

viding the programmer with a set of predefined user interface components. These compo-

nents implement the “look and feel” of the OPEN LOOK Graphical User Interface, developed

by Sun Microsystems, Inc. and AT&T.

This chapter presents a model of XView for the programmer. It is important to understand

this model before you begin writing XView applications. However, you might wish to skim

the concepts presented in this chapter and proceed to Chapter 3, Creating XView Applica-

tions, to examine sample programs.

2.1 Object-oriented Programming

To the programmer, XView is an object-oriented toolkit. XView objects can be considered

building blocks from which the user interface of the application is assembled. Each piece

can be considered an object from a particular package. Each package provides a list of pro-

perties from which you can choose to configure the object. By selecting objects from the

available packages, you can build the user interface for an application.

XView is based on several of the fundamental principles of object-oriented programming:

• Objects are represented in a class hierarchy.

• Objects are opaque data types.

• Objects have attributes which can be set via message passing functions.

• Objects may have callback procedures that are triggered by events.

We will look at how these concepts are implemented in XView in the sections that follow.

XView Programmer’s

Model

The XView Programmer’s Model 17

2.1.1 Object Class Hierarchy

XView defines classes of objects in a tree hierarchy. For example, frame is a subclass of the

more general class window, which in turn is a subclass of drawable. Drawable, like user

interface object classes, is a subclass of the Generic Object class. Figure 2-1 shows the

XView class hierarchy and the relationships between the classes. Each class has identifying

features that make it unique from other classes or packages. In XView, a class is often called

a package, meaning a set of related functional elements. However, there are XView pack-

ages that are not members of the object class hierarchy, such as the Notifier package.

Server

Cursor

Generic

Object

Screen

(Drawable)

Fullscreen

Font

Menu

Selection

Item

(Selection)

Drop Site

Notice

Frame

Openwin

Tty

Icon

Scrollbar

DRAGDROP

Window

Server

Image

Selection

Owner

Selection

Requestor

Canvas

Textsw

Cms

Generic

Panel Item

Your

Panel Item

Panel

Figure 2-1. XView class hierarchy

Some objects are visual and others are not. Examples of visual objects include windows,

scrollbars, frames, panels, and panel items. Nonvisual objects are objects which have no

appearance, per se, but they have information which aids in the display of visual objects.

Examples of nonvisual objects include the server, screen, and font objects. The screen, for

example, provides information such as the type of color it can display or the default fore-

ground and background colors that objects might inherit. The display can provide informa-

tion about what fonts are available for objects that display text.

18 XView Programming Manual

All objects, both visual and nonvisual, are a part of this object classing system. The system is

extensible, so you can create new classes that might or might not be based on existing

classes.

XView uses static subclassing and chained inheritance as part of its object-oriented model.

All objects of a particular class inherit the properties of the parent class (also known as a

superclass). The Generic Object XV_OBJECT contains certain basic properties that all objects

share. For example, the same object can appear in many places on the screen to optimize

storage. To keep a record of this, the Generic Object maintains a reference count of its

instances. Since all objects have an owner, the parent of the object is stored in a field of the

generic part of the object. As the needs of an object get more specific to a particular look or

functionality, lower-level classes define properties to implement it.

Each class contains properties that are shared among all instances of that object. For

example, panels are a part of the PANEL package, which has properties that describe, among

other things, its layout (horizontal or vertical) or the spacing between items (buttons) in the

panel. All panels share these properties, even though the state of the properties might differ

for each instance of the object.

As mentioned earlier, XView uses subclassing so that each package can inherit the properties

of its superclass. The PANEL package is subclassed from the WINDOW package, which has pro-

perties specific to all windows, such as window dimensions, location on the screen, border

thickness, depth, visual, and colormap information. The WINDOW package is subclassed from

the root object XV_OBJECT, as are all objects, and the panel can access generic information

such as the size and position of itself.

2.1.2 Object Handles

When you create an object, the XView function returns a handle for the object. Later, when

you wish to manipulate the object or inquire about its state, you pass its handle to the appro-

priate function. This reliance on object handles is a way of information-hiding. The handles

are opaque in the sense that you cannot see through them to the actual data structure which

represents the object.

Each object type has a corresponding type of handle. Since C does not have an opaque

type, all the opaque data types mentioned above are typedef’d to the XView type

Xv_opaque or Xv_object.

In addition to the opaque data types, there are several typedefs that refer not to pointers

but to structures: Event, Rect, and Rectlist. Generally pointers to these structures are

passed to XView functions, so they are declared as Event *, Rect *, etc. The reason that

the asterisk (*) is not included in the typedef is that the structures are publicly available.

XView Programmer’s

Model

The XView Programmer’s Model 19

Table 2-1 lists each XView object, its owner, the package that defines it, and its data type.

Table 2-1. XView Objects, Owners, Packages, and Data Types

Name Owner Package Data Type

canvas frame CANVAS Canvas

canvas view window or screen CANVAS_VIEW Canvas_view

cms window CMS Cms

cursor window or screen CURSOR Xv_Cursor

drag drop window DRAGDROP Dnd

drop site item window DROP_SITE_ITEM Drop_site_item

font root window FONT Xv_Font

frame frame or root window FRAME Frame

base frame frame or root window FRAME_BASE

command frame frame or root window FRAME_CMD

property frame frame or root window FRAME_PROPS

fullscreen root window FULLSCREEN Fullscreen

icon window or screen ICON Icon

menu server MENU Menu

command menu null MENU_COMMAND_MENU Menu

choice menu null MENU_CHOICE_MENU Menu

pullright menu menu item MENU Menu

toggle menu null MENU_TOGGLE_MENU Menu

menu item menu MENUITEM Menu_item

openwin frame OPENWIN Openwin

notice window NOTICE Xv_Notice

panel frame PANEL Panel

panel button panel PANEL_BUTTON Panel_button_item

panel choice panel PANEL_CHOICE Panel_choice_item

panel drop site panel PANEL_DROP_SITE Panel_drop_site_item

panel item panel PANEL_ITEM Panel_item

panel list panel PANEL_LIST Panel_list_item

panel message panel PANEL_MESSAGE Panel_message_item

panel multi-line text panel PANEL_MULTILINE_TEXT Panel_multiline_

text_item

panel numeric text panel PANEL_NUMERIC_TEXT Panel_numeric_

text_item

panel slider panel PANEL_SLIDER Panel_slider_item

panel text panel PANEL_TEXT Panel_text_item

screen null SCREEN Screen

scrollbar panel or canvas SCROLLBAR Scrollbar

selection window SELECTION Selection

selection owner window SELECTION Selection_owner

selection requestor window SELECTION Selection_requestor

selection item selection owner SELECTION_ITEM Selection_item

server null SERVER Server

server image screen SERVER_IMAGE Server_image

20 XView Programming Manual

Table 2-1. XView Objects, Owners, Packages, and Data Types (continued)

Name Owner Package Data Type

text subwindow frame TEXTSW Textsw

tty frame TTY Tty

window frame WINDOW Xv_Window

2.2 Attribute-based Functions

A model such as that used by XView, which is based on complex and flexible objects, pres-

ents the problem of how the client is to manipulate the objects. The basic idea behind the

XView interface is to provide a small number of functions, which take as arguments a large

set of attributes. For a given call to create or modify an object, only a subset of all applicable

attributes will be of interest.

2.2.1 Creating and Manipulating Objects

There is a common set of functions that allows the programmer to manipulate any object by

referencing the object handle. The functions are listed in Table 2-2.

Table 2-2. Generic Functions

Function Role

xv_init()

Establishes the connection to the server, initializes the Notifier and the

Defaults/Resource-Manager database, loads the Server Resource

Manager database, and parses any generic toolkit command line

options.

xv_create() Creates an object.

xv_destroy() Destroys an object.

xv_find() Finds an object that meets certain criteria; or if the object doesn’t exist,

creates it.

xv_get() Gets the value of an attribute.

xv_set() Sets the value of an attribute.

Using these six routines, objects can be created and manipulated from all packages available

in XView. When the programmer wants to create an instance of an object from a certain

package, the routine xv_create() is used. For example:

Panel panel;

panel = xv_create(panel_parent, PANEL, NULL);

Here, an instance of a panel has been created from the PANEL package. All its attributes are

set to the panel’s default properties because no object-specific attributes have been specified.

XView Programmer’s

Model

The XView Programmer’s Model 21