Volume 7B: XView Reference Manual

1

XView Package Summary

This section provides a brief introduction to XView and then goes on to introduce each of the

XView packages. The packages are described in alphabetical order; their order in this sec-

tion does not correspond to how they are used in any particular application. Refer to the

XView Programming Manual for a general introduction to XView and for details on creating

and working with XView objects.

The last part of this section provides a description of the Notifier. The Notifier maintains the

flow of control in an application. The Notifier controls XView’s notification-based event

handling using callback procedures supplied by application programmers. Also refer to the

XView Programming Manual for more information on the Notifier.

1.1 XView and OPEN LOOK

XView provides a set of windows that include:

• Canvases on which programs can draw.

• Text subwindows with built-in editing capabilities.

• Panels containing items such as buttons, choice items, and sliders.

•

TTY subwindows that emulate character-based terminals.

These windows are arranged as subwindows within frames, which are themselves windows.

Frames can be transitory or permanent. Transient interactions with the user can also take

place in menus which can pop up anywhere on the screen.

An important feature of the XView Toolkit is that it implements the OPEN LOOK Graphical

User Interface (GUI). The OPENLOOK GUI provides users with a simple, consistent, and

efficient interface.

OPENLOOK is supported by Sun and AT&T as the graphical user interface standard for Sys-

tem V Release 4. Users and developers benefit from a standard because it ensures consistent

behavior across a number of diverse applications. Programmers can concentrate on the

design of the application without having to “invent” a user interface for each application.

XView was built based entirely on OPENLOOK specifications that could be mapped easily

into the X Window System.

XView Package

Summary

XView Package Summary 3

The visual design of OPEN LOOK is restrained. The design of each component in the user

interface is simple and uncomplicated. The interface is based on a few simple concepts that

result in a system that is easy to learn initially. And an XView application is relatively

simple, and is easy to implement because many of the default values of interface components

work well for most applications.

The definitive document on OPEN LOOK for application programmers is the OPEN LOOK

Graphical User Interface Style Guide.

1.2 XView Packages

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 1-1 shows the

XView class hierarchy. 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 packages 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 1-1. XView class hierarchy

4 XView Reference Manual

Some objects are visual and others are not. Visual objects include windows, scrollbars,

frames, panels, and panel items, among others. 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.

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.

1.2.1 Object Handles

When you create an object, an 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 Package

Summary

XView Package Summary 5

1.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 the set of all

applicable attributes will be of interest.

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

Table 1-1. 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. Table 1-2 lists the XView packages. Each of these packages is introduced in this

section.

Table 1-2. XView Packages

CANVAS NOTICE PANEL_NUMERIC_TEXT

CMS PANEL PANEL_SLIDER

CURSOR PANEL_ITEM PANEL_TEXT

DRAGDROP PANEL_BUTTON SCREEN

DROP_SITE_ITEM PANEL_CHOICE SCROLLBAR

FONT PANEL_CHECK_BOX SELECTION

FRAME PANEL_DROP_TARGET_ITEM SERVER

FULLSCREEN PANEL_GAUGE TEXTSW

ICON PANEL_LIST TTYSW

MENU PANEL_MESSAGE WINDOW

MENU_ITEM PANEL_MULTILINE_TEXT

6 XView Reference Manual

1.3 The CANVAS Package

A canvas is the area in which an application displays graphics and handles its input. An

XView canvas object allows the user to view a graphic image that is similar to a painter’s

canvas. This image may be too large for the window or even too large for the display screen.

The viewable portion of the graphic image is part of image’s viewport or view window.

Many different views of an image can use the same canvas object. While each view main-

tains its own idea of what it is displaying, the canvas object manages all the view windows as

well as the graphic image that all views share. The ability for the canvas to maintain differ-

ent views of the graphic image is a property that is inherited from the canvas’s superclass, the

OPENWIN package. These properties provide for splitting and scrolling views. You cannot

create a canvas object with multiple views; views are split and joined generally by the user

via the attached scrollbars. It is possible to programmatically split and scroll views, but

OPENLOOK’s interface specification indicates that scrollbars provide the ability to split

views. When a view is split, each new view may be further split into two more views, and so

on. All the views are still a part of the same canvas object.

There are three types of windows involved with the canvas object:

Canvas Subwindow Owned by a frame and manages one or more views. The canvas is

subclassed from the OPENWIN package so all Openwin attributes must

be set to the instance of the canvas object.

View Window Represents the visible portion of the paint window—whenever the

paint window associated with a view window changes, it is reflected

in the view window. If there is more than one view window, the

views are tiled. Vertical and/or horizontal scrollbars can be attached

to the view subwindow to allow the user to modify which portion of

the paint window is displayed for that particular view. The size of the

view window can vary among all the views. Only views can be split.

No graphics or user events take place in this window.

Paint Window Graphics and events (mouse/keyboard) take place in the paint win-

dow. There is one paint window per view window. All paint win-

dows in the canvas are the same size regardless of the size of the can-

vas or of the corresponding view windows. When a view is split, the

old view reduces in size and a new view is created. With the new

view, a new paint window is created that is identical to the paint win-

dow from the old view. This includes the same visual, width, height,

depth and graphic image. However, callback functions and event

masks are not inherited and must be manually installed in all new

paint windows.

The CANVAS package is defined in the header file <xview/canvas.h> so programs that use can-

vases must include this file. This header file includes the OPENWIN package automatically.

The owner of a canvas must be a FRAME object.

XView Package

Summary

XView Package Summary 7