Volume 7B: XView Reference Manual

Figure 1-17. Panel item created with the PANEL_TEXT package

1.13.2 Scrollable Panels

Scrollable panels are not OPEN LOOK-compliant, but are provided for historical reasons.

They are basically just like panels, except that typically not all panel items are in view. A

vertical scrollbar attached to the panel allows the user to navigate to the panel items desired.

Again, because this type of interface is not OPENLOOK-compliant, you are discouraged

from using this package.

Scrollable panels are created the same way panels are, but the package name to use is

SCROLLABLE_PANEL

. However, the scrollable panel package does not create the scrollbars,

you must create them separately.

1.14 The SCREEN Object

An Xv_Screen is associated with virtually all XView objects. To use the Xv_Screen

object, you must include the file <xview/screen.h>. The Xv_Screen object carries useful

information such as the screen number of the root window, all the visuals, the colormap, the

server and so on, that are associated with that screen.

The Xv_Screen object differs from the Screen data structure defined by Xlib and, in fact,

has nothing to do with the X11 Screen data type (defined in <X11/Xlib.h>).

XView Package

Summary

XView Package Summary 23

1.15 The SCROLLBAR Package

Scrollbars are used to change what you view in a subwindow. For instance, in a text subwin-

dow, scrollbars are used to scroll through a document. In a canvas subwindow, scrollbars can

be used to see another portion of the paint window (which can be larger than the canvas

subwindow).

The definitions necessary to use scrollbars are found in the header file <xview/scrollbar.h>.

The owner must be an object subclassed from the OPENWIN package or the FRAME package.

The scrollbar inherits certain attributes from the parent while other attributes are initialized

automatically. For example, if the owner of the scrollbar is a canvas, the scrollbar’s color is

inherited from the canvas, while the scrollbar’s object length is set by the canvas explicitly;

that is, you are not required to set it. This is usually desirable when creating objects that are

used together.

1.16 The SELECTION Package

The X Window System provides several methods for applications to exchange information

with one another. One of these methods is the use of the selections. A selection transfers

arbitrary information between two clients. XView Version 3 provides a selection mechanism

that is implemented using the

SELECTION and SELECTION_ITEM packages. The selection

package and its sub classes, including: the SELECTION_REQUESTOR package and the

SELECTION_OWNER package, allow data to be move between applications or within an appli-

cation. These packages replace the selection service used in previous versions of XView,

which required special functions and structures. The old selection service is still supported;

it is described in Appendix A, The Selection Service, of the XView Programming Manual.

1.17 The SERVER Package

The SERVER package may be used to initialize the connection with the X server running on

any workstation on the network. Once the connection has been made, the package allows

you to query the server for information. xv_init(), the routine that initializes the XView

Toolkit, opens a connection to the server and returns a handle to an Xv_Server object.

While more than one server can be created, xv_init() only establishes a connection to one

server. The server object returned by xv_init() is also the server pointed to by the external

global variable, xv_default_server. Programs that do not save the Xv_Server object

returned by xv_init() can reference this global variable instead.

Subsequent connections to other X11 servers must be made using separate calls to xv_

create(). Note that using separate screens is not the same as establishing a connection to

other servers—the same server can support multiple screens.

24 XView Reference Manual

When making any reference to Xv_Server objects, applications should include

<xview/server.h>. There is no owner for a server, the owner parameter is ignored and you

may pass NULL.

1.18 The TEXTSW Package

This TEXTSW package allows a user or client to display and edit a sequence of ASCII charac-

ters. A text contains a vertical scrollbar but may not contain a horizontal scrollbar. The ver-

tical scrollbar can be used to split views into several views. The font used by the text can be

specified using the TEXTSW_FONT attribute, but only one font per text subwindow can be used,

regardless of how many views there may be.

The contents of a text subwindow are stored in a file or in memory on the client side, not on

the X server. Whether the source of the text is stored on disk or in memory is transparent to

the user. When the user types characters in the text subwindow, the source might be changed

immediately or synchronized later depending on how the text subwindow is configured. The

TEXTSW package provides basic text editing features such as inserting arbitrary text into a file.

It also provides complex operations such as searching for and replacing a string of text.

Applications need to include the file <xview/textsw.h> to use text subwindows.

1.19 The TTYSW Package

The TTY (or terminal emulator) subwindow emulates a standard terminal, the principal dif-

ference being that the row and column dimensions of a tty subwindow can vary from that of a

standard terminal. In a tty subwindow, you can run arbitrary programs, including a complete

interactive shell. Or you can emulate terminal interface applications that use the curses(3X)

terminal screen optimization package without actually running a separate process. The TTY

subwindow accepts the standard ANSI escape sequences for doing ASCII screen manipulation,

so you can use termcap or termio screen-handling routines.

Programs using tty subwindows must include the file <xview/tty.h>. The default tty subwin-

dow will fork a shell process and the user can use it interactively to enter commands. This

program does not interact with the processing of the application in which the TTY subwindow

resides; it is an entirely separate process.

XView Package

Summary

XView Package Summary 25

1.20 The Notifier

The Notifier maintains the flow of control in an application. To understand the basic con-

cepts of the Notifier, we must distinguish between two different styles of input handling,

mainline input and event-driven input, and consider how they affect where the flow of control

resides within a program.

1.20.1 Mainline Input Handling

The traditional type of input handling of most text-based applications is mainline-based and

input-driven. The flow of control resides in the main routine and the program blocks when it

expects input. That is to say, no other portion of the program may be executed while the pro-

gram is waiting for input. For example, in a mainline-driven application, a C programmer

will use fgets() or getchar() to wait for characters that the user types. Based on the

user’s input, the program chooses an action to take. Sometimes, that action requires more

input, so the application calls getchar() again. The program does not return to the main

routine until the processing for the current input is done.

The tight control represented by this form of input handling is the easiest to program since

you have control at all times over what to expect from the user and you can control the direc-

tion that the application takes. There is only one source of input—the keyboard—and the

user can only respond to one interface element at a time. A user’s responses are predictable

in the sense that you know that the user is going to type something, even if you do not know

what it is.

1.20.2 Event-driven Input Handling

Windowing systems are designed such that many sources of input are available to the user at

any given time. In addition to the keyboard, there are other input devices, such as the mouse.

Each keystroke and mouse movement causes an event that the application might consider.

Further, there are other sources of events such as the window system itself and other

processes. Another aspect of event-driven input handling is that you are not guaranteed to

have any predictable sequence of events from the user. That is, a user can position the mouse

on an object that receives text as input. Before the user is done typing, the user can move the

mouse to another window and select a panel button of some sort. The application cannot

(and should not) expect the user to type in window A first, then move to window B and select

the button. A well-written program should expect input from any window to happen at any

time.

26 XView Reference Manual

1.20.3 Functions of the Notifier

The Notifier can do any of the following:

• Handle software interrupts—specifically, UNIX signals such as SIGINT or SIGCONT.

• Notice state changes in processes that your process has spawned (e.g., a child process that

has died).

• Read and write through file descriptors (e.g., files, pipes and sockets).

• Receive notification of the expiration of timers so that you can regularly flash a caret or

display animation.

• Extend, modify or monitor XView Notifier clients (e.g., noticing when a frame is opened,

closed or about to be destroyed.)

• Use a non-notification-based control structure while running under XView (e.g., porting

programs to XView).

The Notifier also has provisions, to a limited degree, to allow programs to run in the Notifier

environment without inverting their control structure.

1.20.4 How the Notifier Works

When you specify callbacks or notify procedures, the XView object specified is said to be the

client of the Notifier. Generally stated, the Notifier detects events in which its clients have

expressed an interest and dispatches these events to the proper clients in a predictable order.

In the X Window System, events are delivered to the application by the X server. In XView,

it is the Notifier that receives the events from the server and dispatches them to its clients.

After the client’s notify procedure processes the event, control is returned to the Notifier.

1.20.4.1 Restrictions

The Notifier imposes some restrictions on its clients. Designers should be aware of these

restrictions when developing software to work in the Notifier environment. These restric-

tions exist so that the application and the Notifier do not interfere with each other. More pre-

cisely, since the Notifier is multiplexing access to user process resources, the application

needs to respect this effort so as not to violate the sharing mechanism.

For example, a client should not call signal (3). The Notifier is catching signals on behalf

of its clients. If a client sets up its own signal handler, then the Notifier will never notice the

signal. The program should call notify_set_signal_func() instead of signal (3).

XView Package

Summary

XView Package Summary 27