Volume 7A: XView Programming Manual

Figure 2-10. A control area in a command window

Figure 2-11 shows an example of a pop-up menu on the left; on the right, a pullright submenu

is displayed.

Pushpins can be used in some menus, allowing them to be pinned so that the menu remains

on the screen for repeated use.

Figure 2-11. Example of a pop-up menu with a pullright submenu

32 XView Programming Manual

2.4.4.5 Scrollbars

Scrollbars implement the OPEN LOOK metaphor of an elevator on a cable. These components

are shown in Figure 2-12.

Figure 2-12. Vertical scrollbar components

A scrollbar is an object that can exist independently or attach itself to various types of

subwindows. The scrollbar is subclassed from the WINDOW class since it is a visual object.

However, because its functionality is very tightly bound to other objects, the scrollbar is

sometimes considered to be a property of those objects.

OPENWIN subclasses (canvas and

text-based packages) require scrollbars to provide splittable views, and scrollbars can be

created automatically by such objects. Typically, it is your responsibility to pass a hint to the

object that it should create the scrollbar using the appropriate attribute-value pair. Neverthe-

less, scrollbars can be manually attached or detached to OPENWIN objects, or they can be

created independently of these objects for other purposes entirely.

The SCROLLBAR package manages only the scrollbar window. It does not control the window

to which it is attached. When a scrolling action results from the user clicking on a portion of

the scrollbar, the window to which the scrollbar is attached must modify its data (a view in

most cases). It is not the scrollbar’s responsibility to notify the window it is attached to. The

scrollbar informs the object interested in its scrolling by use of callback routines that the

owner of the scrollbar must install.

Scrollbars can be oriented vertically or horizontally, but some packages might not allow a

particular scrollbar orientation. Text subwindows, for example, contain vertical scrollbars by

default but do not permit horizontal scrollbars.

XView Programmer’s

Model

The XView Programmer’s Model 33

2.4.4.6 Icons

An icon is a small image representing the application when the application’s frame is in a

closed, or iconified, state. The ICON package is very small. It is subclassed from the WINDOW

package because it is a window that displays graphics and accepts input. The only attributes

that you can set in the ICON package specify the image to display in the window and the

geometry of the image. Other important attributes that an icon can have (such as width,

height, label, and font) are attributes of the generic class.

2.4.5 Nonvisual Objects

There are several nonvisual objects that cannot be represented on the screen but are sub-

classed from the Generic Object:

CMS Colormap segments (cms) are objects that are associated with windows

which provide their color specifications. Cms objects may be shared by

multiple windows.

DROP_SITE_ITEM The drop site item is a rectangle that is an area used for dragging an

object and dropping data associated with the object onto the drop site’s

application.

FONT The font package allows the programmer to request fonts of varying

attributes such as font family and style. Fonts can be accessed by name,

size or scaling.

SCREEN This object describes the visual and other characteristics of the physical

screen. This object is separate from the Xlib SCREEN object.

SELECTION This package allows clients to transfer data between applications.

SERVER This package interacts with the X server. The window-server is the pro-

gram that does the drawing to the screen and receives the user’s input.

The server also maintains font information and user-configurable

resources, which can be set for specific applications.

These objects are closely tied with the X Window System, and they are manipulated by mak-

ing requests to set or get attributes from X.

34 XView Programming Manual

2.5 The Notifier Model

XView is a notification-based system. The Notifier acts as the controlling entity within a

user process, reading input from the operating system and formatting it into higher-level

events, which it distributes to the different XView objects.*

2.5.1 Callback Style of Programming

In the conventional style of interactive programming, the main control loop resides in the

application. An editor, for example, will read a character, take some action based on the

character, then read the next character, and so on. When a character is received that repre-

sents the user’s request to quit, the program exits. Figure 2-13 illustrates this conventional

approach.

process input

quit request?

end

read input

start

Figure 2-13. Flow of control in a conventional program

Notification-based systems invert this straight line control structure. The main control loop

resides in the Notifier, not the application. The Notifier reads events and notifies, or calls out

to, various procedures which the application has previously registered with the Notifier.

These procedures are called notify procs or callback procs. This control structure is shown in

Figure 2-14.

*XView events are in a form that you can easily use: an ASCII key has been pressed, a mouse button has been pressed

or released, the mouse has moved, the mouse has entered or exited a window, etc. Events are described in detail in

Chapter 6, Handling Input.

XView Programmer’s

Model

The XView Programmer’s Model 35

process event

call appropriate

callback procedure

did callback

procedure request

quit?

No

Yes

return to application

register

callback procs

with Notifier

call Notifier

Application Code

read input

Notifier

start

end

Figure 2-14. Flow of control in a Notifier-based program

2.5.2 Why a Notification-based System?

If you are not used to it, this callback style of programming takes some getting used to. Its

big advantage is that it takes over the burden of managing a complex, event-driven environ-

ment. In XView, an application typically has many objects. In the absence of a centralized

Notifier, each application must be responsible for detecting and dispatching events to all the

objects in the process. With a centralized Notifier, each component of an application

receives only the events the user has directed towards it.

36 XView Programming Manual