Volume 7B: XView Reference Manual

1.4 The CMS Package

The X Window System has various ways of allocating, specifying, and using colors. While

all of these methods are available to applications without XView intervening, XView pro-

vides its own model for color specification that may be used as an alternative. It does not

provide anything more than what is already available, but it may provide a simpler interface

to request and specify colors. This model is especially useful when specifying colors for

XView objects, such as panel buttons and scrollbars.

XView applications deal with color by using colormap segments. Window-based objects

(canvases, panels, textsw, etc.) use colormap segments to get their colors. These objects get

a default colormap segment when they are created, but you can assign a new one using the

WIN_CMS attribute. Colormap segments must be applied to windows to assure that the win-

dow can access the color you are attempting to draw into.

A colormap segment from the CMS package is a subset of the available cells in a colormap on

the X server. These are XView entities (i.e., not Xlib) that provide a veneer over the Xlib

color mechanism. Colormap segments can be created as either static or dynamic and are

derived from an underlying colormap of the same type.

Applications that use color must include the file <xview/cms.h>. The owner of a colormap

segment is the XView screen object with which the colormap is associated. If an owner is

not specified (NULL owner), the default screen of the default server is used as the owner.

1.5 The CURSOR Package

A cursor is an image that tracks the mouse on the display. Each window has its own cursor

which you can change. There are some cursors defined by OPEN LOOK that correspond to

specific window manager operations such as resizing or dragging windows. For these cases,

you cannot redefine a cursor. However, for windows in your application, you can assign any

cursor image you like.

To use the

CURSOR package, include the header file <xview/cursor.h>. The owner of the cur-

sor may be any XView object. The root window associated with the XView object is used

internally by the CURSOR package. If the owner is NULL, then the root window of the default

screen is used.

A number of predefined cursors are available in the CURSOR package for use as OPEN LOOK

cursors. To use these cursors, you may specify the

CURSOR_SRC_CHAR and CURSOR_

MASK_CHAR attributes with certain predefined constants as values for these attributes. There

are some OPEN LOOK cursor defines prefixed by OLC_ in <xview/cursor.h>.

The hotspot on a cursor is the location in which the cursor is located if the user generates an

event like pressing a mouse button or typing at the keyboard, or if you were to query its posi-

tion. For example, if a cursor is shaped like an arrow, the hotspot should be at the tip of the

arrow. If the hotspot for a cursor were set to (0, 0) then the hotspot would be the upper-left

corner of the image used. A cursor shaped like a bull’s eye (16x16) might have its hotspot at

(7, 7) to indicate that the focus for the cursor is in the middle.

8 XView Reference Manual

1.6 The DRAGDROP and DROP_SITE_ITEM Packages

Drag and drop operations are facilitated using two packages: the DRAGDROP package and the

DROP_SITE_ITEM package. DRAGDROP is subclassed from the SELECTION_OWNER package and

represents the source of the drag. DROP_SITE_ITEM is subclassed from the Generic package.

A drop-site item indicates a destination that is a valid drop-site. A valid drop-site is a region

that may either preview a drop or receive a drop. A drag and drop operation, such as the

familiar procedure of dragging a file from a folder and dropping it into another folder, allows

you to easily transfer data.

Applications need to include the file <xview/dragdrop.h> to use these packages. Drag and

drop supports drop previewing where the drop-site image changes to show that it is a valid

drop-site and drag feedback where the pointer image (cursor) changes to indicate that an item

is being dragged.

Attributes for DRAGDROP use a DND_ prefix. Attributes for DROP_SITE_ITEM use a DROP_SITE

prefix. The owner of either a DRAGDROP object, or a DROP_SITE_ITEM object is a window.

1.7 The FONT Package

In X, a large number of fonts are provided on the server. Deciding which font to use and then

trying to specify fonts by name can be difficult since there are many different styles and sizes

of fonts. Most fonts are used to render text strings. So the images, or glyphs, represent a

character set-defined language used. However, a font may be built to support glyphs for

other languages or to provide a set of glyphs. Fonts are stored on the server and are associ-

ated with the display of your workstation. The font ID is stored in the graphics context (GC),

which is used by Xlib functions like XDrawString(). Using fonts to render text is perhaps

the most common application. For example, the Courier font family displays the classic

typewriter or constant-width character set. This text is set in Times-Roman, a proportionally

spaced font. Often within a font family, there are different styles, such as bold or italic, and

different point sizes.* For example, Helvetica bold 14 refers to the Helvetica font family;

bold is the style and 14 is the point size.

Not all server fonts have a variety of styles and sizes. These special-purpose fonts are gener-

ally specified by name only—there are no corresponding styles or families for these fonts.

When accessing fonts, you typically want to specify a font either by name or by the family,

style, and size or scale of the font. In addition, XView provides an interface for determining

the dimensions (in pixels) of characters and strings rendered in a specified font.

OPENLOOK uses predefined fonts for certain items such as panel buttons and other user

interface elements. These items cannot be changed, but you can assign text fonts to panel

choices, text subwindows and other types of windows.

*Note that point sizes on workstations are based on pixels, whereas point sizes for typesetters and printers are based

on inches.

XView Package

Summary

XView Package Summary 9

Applications that use the FONT package must include the header file, <xview/font.h>. In

XView, when a font object is created, it loads the font from the X server. When we say, “cre-

ate a font,” we really mean, “load a font from the server and create an XView font object

associated with that font.”

While fonts can be created using xv_create(), it may not be necessary to create a new

instance of a font. Fonts are typically cached on the server, and XView may already have a

handle to a particular font. Therefore, you would obtain a handle to the font, if it already

exists, rather than open another instance of the same font. xv_find() can be used to return

the handle of an existing font. If the handle does not exist, xv_find() can create a new

instance of the font.

The owner of the font is usually the window in which the font is going to be used. The actual

X font is loaded from the server associated with the owner object. If the owner is NULL, the

default server is used. Fonts may be used on any window, or in memory pixmaps, or a server

image (a Server_image object), but these objects must have the same display (Server)

associated with them as the font, or you will get an X Protocol error. What this means, is that

a font can only be used on the server on which it was created.

1.8 The FRAME Package

A frame is a container for other windows. It manages the geometry and placement of

subwindows that do not overlap and are fixed within the boundary of the frame. The

OPENLOOK specification refers to subwindows, or panes, as tiled windows because they do

not overlap one another. Subwindow types include canvases, text subwindows, panels, and

scrollbars. These subwindows cannot exist without a parent frame to manage them.

The FRAME package provides the following capabilities:

• A communication path between the application and the window manager.

• A mechanism to receive input for the application.

• A visual container for user interface objects.

• A method to group windows with related functionality.

• A mechanism to manage footers.

A frame depends upon the window manager for its decorations and many basic operations.

The

FRAME

package does not manage headers (title bars), resize corners, or the colors of those

objects. These are all strictly functions of the window manager. The application gives hints

to the window manager about some of these attributes through the FRAME package (including

not to display decorations at all if so desired), but results vary depending on which window

manager the user is running.

10 XView Reference Manual

Frames do not manage events; this task is left up to the windows that the frame manages.

That is, frames do not get mouse and keyboard events and propagate them to child windows.

While frames are subclassed from the window package, the frame’s window rarely sees any

events at all, and if they do, these are not intended to be processed by the application pro-

grammer.

Basically, two types of frames are available in XView: base frames and command frames.

The main frame of the application is called the base frame. The base frame resides on the

root window; its handle is passed to xv_main_loop() to begin application processing.

A special kind of frame, called a command frame, is created with a panel subwindow by

default. Command frames are useful as help frames, property frames, and such defined by

OPENLOOK. Programmatically, a command frame is no different from a frame with one

subwindow that is a panel and a pushpin if run under the olwm (OPEN LOOK window

manager).

A base frame’s parent or owner, is the root window, whereas a subframe’s parent is another

frame (either a base frame or a subframe). When a frame goes away (quit or close), all of its

child windows, including subframes, also go away. For example, assume you create a com-

mand subframe to display application-specific help. When this command subframe is

activated, it might display explanatory text along with an OK button to dismiss the help. If

you close the base frame, the help subframe also closes.

XView allows for multiple frames that are not children of the base frame. For instance, you

could create a help frame that is independent of the application’s base frame. The parent of

this frame is the root window of the display and not the base frame. The help frame will

remain visible even if the base frame goes away. The term subframe defines a relationship

among frames at creation time and a slight difference in functionality.

1.9 The FULLSCREEN Package

The FULLSCREEN package is used to grab the X server, and an instance of it is considered a

nonvisual object. Nonvisual objects are not viewed on the screen, but they have a place in

the XView object hierarchy. Nonvisual objects are typically used internally by XView and

are seldom used directly in an application. Working with FULLSCREEN objects may not be

essential to all programmers.

XView Package

Summary

XView Package Summary 11

1.10 The ICON Package

A user may close an application to save space on the display. The program is still running

and it may even be active, but it is not receiving input from the user. In order to represent the

application in its closed state, an icon is used. An icon is a small picture that represents the

application.

The graphic image that icons use may be used for other purposes and, therefore, may be

shared among other objects in the application. But the icon image should be designed to eas-

ily identify the application while in a closed state. Icons may also have text associated with

them. Space is limited, so the text is usually the name of the application.

To use the ICON package, include the header file <xview/icon.h>. The owner of an icon is a

base frame, but it may be created with a NULL owner. Once an icon is assigned to a frame, the

owner of the icon is changed to that frame. This is an example of delayed binding.

When destroying an icon, the server image associated with the icon is not destroyed—it is

the application programmer’s responsibility to free the server image and the pixmap associ-

ated with the icon if needed.

1.11 The MENU and MENUITEM Packages

Menus play an important role in an application’s user interface. An OPEN LOOK menu may

display text or graphics. Menus may be attached to most XView objects such as menu but-

tons, scrollbars, or text subwindows, or they may exist independently from objects and be

displayed on demand.

The user may cause a menu to be pinned up by selecting an optional pushpin in the pop-up

menu. When this happens, the menu is taken down and a corresponding command frame is

put up at the same location. Panel items in the pinup window correspond to the menu items

in the menu. Once a menu has been pinned up, the user continues to interact with it just as if

the menu were popped up each time. Menus that are used frequently are good candidates for

having pushpins so the user does not have to repeat the sequence of redisplaying the menu to

make selections.

OPENLOOK requires that menus have titles. Menus or submenus that originate from menu

buttons or pullright items do not need to have titles, since the name of the menu button or

menu item acts as the title.

Fonts may not be specified in either menu items or menu titles; menu items follow the same

constraints outlined for panel buttons. However, if text is not used, then menu items may

contain graphic images, in which case, the font is of no concern. That is, you could specify a

Server_image that has a string rendered in a particular font.

12 XView Reference Manual