Volume 7A: XView Programming Manual

Mouse Keyboard

Display

cmdtool(CONSOLE)-/bin/csh

total 49

1 sbin/ 3 etc/ 1 preserve/

1 5include 1 hosts/ 1 pub/

1 5lib/ 2 include/ 1 sccs

1 Xlir3@ 1 kvm 1 share/

1 adm@ 4 lib/ 1 spool@

6 bin/ 1 local/ 1 sqps

1 boot/ 8 lost+found/ 1 stand/

1 demo/ 1 man@ 1 sys@

1 diag/ 1 mdc/ 1 tmp@

1 dict 1 old/ 2 ucb/

colorful-96%

Workspace

Utilities

Properties...

Exit...

colorful:/usr

colorful-19%

Network

Application

XView Toolkit

Xlib

Device

X11 Server Window Manager

Figure 1-4. The software architecture of X applications

Note that using a toolkit does not preclude calling Xlib directly to accomplish certain tasks

such as drawing. In XView, graphics rendering is done most efficiently by using Xlib draw-

ing routines, for instance.

1.3 Extensions to X

Another thing to know about X is that it is extensible. The code includes a defined mecha-

nism for incorporating extensions, so that vendors are not forced to modify the existing sys-

tem in incompatible ways when adding features. An extension requires an additional piece

of software on the server side and an additional library at the same level as Xlib on the client

side. After an initial query to see whether the server portion of the extension software is

installed, these extensions are used just like Xlib routines and perform at the same level.

Among the extensions currently being developed are support for 2D spline curves, for 3D

graphics, and for Display PostScript

. These extensions can be used in toolkit applications

just like Xlib can.

8 XView Programming Manual

1.4 The Window Manager

Because multiple applications can be running simultaneously, rules must exist for arbitrating

conflicting demands for input. For example, does keyboard input automatically go to which-

ever window the pointer is in, or must the user explicitly select a window for keyboard input?

Unlike most window systems, X itself makes no rules about this kind of thing. Instead, there

is a special client called the window manager that manages the positions and sizes of the

main windows of applications on a server’s display. The window manager is just another cli-

ent, but by convention, it is given special responsibility to mediate competing demands for

the physical resources of a display including screen space, color resources, and the keyboard.

The window manager allows the user to move windows around on the screen, resize them,

and usually start new applications. The window manager also defines much of the visible

behavior of the window system, such as whether windows are allowed to overlap or are tiled

(side by side), and whether the keyboard focus simply follows the pointer from window to

window or whether the user must click a pointer button in a window to change the keyboard

focus (click-to-type).

Applications are required to give the window manager certain information that helps the win-

dow manager mediate competing demands for screen space or other resources. For example,

an application specifies its preferred size and size increments. These are known as window

manager hints because the window manager is not required to honor them. The XView

Toolkit provides an easy way for applications to set the window manager hints.

The conventions for interaction with the window manager and with other clients have been

standardized by the X Consortium as of July 1989 in a manual called the Inter-Client Com-

munications Conventions Manual (ICCCM, for short). The ICCCM provides basic policy

intentionally omitted from X itself, such as the rules for transferring data between applica-

tions (selections), transfer of keyboard focus, layout schemes, colormap installation, and so

on. As long as applications and window managers follow the conventions set out in the

ICCCM, applications created with different toolkits will be able to coexist and work together

on the same server. Toolkit applications should be immune to the effects of the change from

earlier conventions.

1.5 Handling Events

The window that X provides is the connection between the XView application and the X

server. The reason X windows are important to XView is that these windows are the input

targets for the user’s focus. They are the actual objects that get events from the user and pass

the events through to the XView world.

An X event is a data structure sent by the server that describes something that just happened

that is of interest to the application. The sources of events are the user’s input, the window

system, the operating system, and the application programs. For example, the user’s pressing

a key on the keyboard or clicking a mouse button generates an event, and a window’s being

moved on the screen also generates events if it changes the visible portions of other applica-

tions. It is the server’s job to distribute events to the various windows on the screen.

XView and the

X Window System

XView and the X Window System 9

In XView, between the server and the application, there is an event dispatch mechanism

called the Notifier, as shown in Figure 1-5.

XView

Client

Server

Network

Pipe

XView

Notifier

Translate

Events

Distribute

Events

Application

Event

Procedure

Application

Event

Procedure

Application

Event

Procedure

Signal

Figure 1-5. The Notifier exists between the server and the XView application

After the set-up phase of the application, where you create XView objects such as buttons or

scrollbars and determine how they will interact with your application code, you have several

choices for input distribution. The simplest method is to hand off control of your application

to XView. From then on, the XView Notifier automatically distributes events to the objects

created by the application. These objects process many events internally so that your appli-

cation does not need to get involved.

The key point is that your application is only told about events for which it specifically

requested to be notified. By responding to these events, the application can perform its tasks.

For example, if the user types the letter A in a window, X will pass the event to XView, which

10 XView Programming Manual

in turn can pass it to the application. An application’s event handler can interpret this event

and display the letter typed in the window. Finally, control returns to the top level so the next

event can be read. This is a typical cycle of events that happens for each event generated by

the user.

If the application created a scrollbar, then it would track certain events, such as when the

scroll button is pressed. XView actually sends a request to the X server to create the X win-

dow that will become part of the scrollbar object. In the application’s request, it can ask to

be notified about or to ignore certain user events in the X window created.

The window system dictates which window gets an event. If the window currently has the

keyboard focus and that window does not want to process the event, it has the option of

throwing away the event or dropping it to the window below it. This is usually the parent of

the window. For instance, if a panel item gets a keyboard press (the user typed an A) and if

the panel item does not want to deal with the event, then the panel item might be configured

so that the event is passed to the item’s parent: the panel itself.

The Notifier does not just do input distribution; it also allows selection of different input

sources. In addition to handling window system events, your application can also handle a

number of interrupts that might be generated by the operating system. Your application can

respond to signals, input on a file descriptor and interval timers. You could also pass events

between clients in the same process, interpose on a Notifier client to change its behavior, and

receive notification on the death of a child process which you have spawned. The use of

some of these input sources requires you to call the Notifier directly. The Notifier is covered

again in the next two chapters as well as in Chapter 20, The Notifier.

1.6 Development of the XView Toolkit

Over the years, Sun Microsystems, Inc. has developed several toolkits, each more well-

defined, more functional, and aesthetically superior than the last. SunView 1 was perhaps the

first well-accepted user interface toolkit Sun provided. It had all the basic elements neces-

sary to make a functional user interface—including a well-defined API (application pro-

grammer’s interface). It introduced the attribute-value interface, which we’ll examine in

more detail in Chapter 2, The XView Programmer’s Model. It has very few procedure calls.

For instance, you use a single function to create all user interface objects. You have the

option of using default values, in which case the object is created with only a few lines of

code, or of setting the values of specific attributes as required. These attributes can be set at

the time the object is created, or later on, by using a different function.

The SunView 1 Toolkit was based on SunWindows, a kernel-based window system. It

required that a single computer control both the application and the user’s display and key-

board. The X Window System represents a new generation of window systems. It is server-

based, which means that the client application can run on a different system than the server

that controls the display.

Today there are several thousand SunView applications, and one of the aims of XView is to

make it easy to bring those applications to the X Window System marketplace. In addition,

XView and the

X Window System

XView and the X Window System 11

Sun has made the source code to the XView Toolkit freely available. It will be shipped as

part of the standard MIT X distribution as well as with UNIX System V Release 4.

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. We will look more at all XView

objects when we cover the XView programming model in the next chapter.

1.7 Versions of the XView Toolkit

Since XView was first released, many applications have been developed for XView and

many others have been ported from SunView, as well as from other software platforms.

XView development has continued at Sun; new packages have been written, extensions have

been added, and the existing packages have been improved based on user’s needs. This man-

ual is written for the latest release of XView, Version 3, and it includes descriptions for all

the important improvements available in this XView release.

1.8 OPENLOOK Graphical User Interface

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

User Interface (GUI). The OPEN LOOK GUI aims to provide users with a simple, consistent,

and efficient interface. An example of an OPEN LOOK workspace is shown in Figure 1-6.

OPEN LOOK 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.

A well-defined user interface should be generalized enough so that it can be implemented on

any operating system, windowing system, or graphics display. Because

OPEN LOOK is not

bound by any of these constraints, XView was built based entirely on specifications that

could be mapped easily into the X Window System.

12 XView Programming Manual