Professional Documents
Culture Documents
Creating and
Managing Windows
. indows (0 organize output is not new. It is widely used for graphics as well as
red wdisplays. For examp Ie, many app I'Icatlons
The idea o.fusIng . ror
C 'MS-DOS systems use ch aracter_ Figure 7.1.
onen . d ows, f,or t h'elr user mtenace. A hierarchy of
ch.aracrer-
d windows, or rext wm . C Th e M'acmtos h user mtenace,
. C
Microsoft
windows inX
on.enl~ws,and X use bitmapped graphics windows. Despite the common goal of organizing outpUt
:::Iogical manner, the window systems have varying terminologies, coordinate systems, and ways
of organizing the windows. For example, each window has a parent in X and Microsoft Windows,
but the Macintosh does not have thar concept. To make effective use of windows, you must learn
the terms and concepts that are unique to the window system you are using.
In X, windows are usually rectangular areas of the screen where applications display their output.
Windows can overlap one another on the screen. Typically, each X application has at least one window B.3.1 B.3.2 8.3.3
on the screen. A special X application, the window manager, enables users to arrange the windows
and shuffle them around as if they were pieces of paper on a desktop. One important aspect ofX's
GjB I Cancel I
model of windows is that they are organized in a strict parent-child hierarchy.
Window Hierarchy
All windows in X are organized in a hierarchy:
.• At the top of the hierarchy is the root window, which occupies the entire screen.
~ Every window, except the root, must have a parent.
.• Each window is the child of some other window.
Slacking order of lop·level windows
The main window of an application is a child of the root window. Many more windows usually - - - - - - •• ~ Top
exist within an application's main window. A window can be of arbitrary size, but the server does
not draw any part of a child window that falls outside the boundaries of its parent.
Think of the hierarchy of windows as a family tree, with the root window at the top. A window may
have one or more children and each child may have more children. Figure 7.1 shows a hypothetical
layout of windows together with their tree structure. Notice how there are several levels in the tree,
and there are one or more windows at each level. You can think of the number oflevels as the depth
of the tree, and the windows at the same level as its breadth. X enables you to have as deep a hier-
archy with as much width at each level as you want. Applications routinely use a large number of
windows to build a user interface.
You are already familiar with the terms parent and child. Additionally, the following terms apply to
the window hierarchy:
Stacking Order
.• Sibling. All children of a parent are called siblings. In Figure 7.1, the windows B.l, B.2,
and 8.3 are siblings. They are also called the subwindows of B. x clips all children against the boundary of their parent. In case of overlap among siblings, how-
~ver, the order determines which windows will be fully visible. This order of displaying the siblings
.• Descendant. The descendants of a window are all windows below it in that branch of the
ISknown as the stacking order. If the siblings do not overlap, the order in which they are displaye
hierarchy. Thus, in Figure 7.1, B has nine descendants-the windows B.l, B.2, B.3, B.2.1, does not matter.
B.2.2, B.2.3, B.3.1, 8.3.2, and B.3.3. None of these windows is a descendant of A.
Descendants are also referred to as inferiors. The stacking order of the root window's children is very important, because these are the top-level
.• Ancestor. The ancestors of a window are all windows above it in that branch of the family windows of applications. For example, in Figtire 7.1, windows A and B are siblings of the root, with
tree. Thus, the root window is the ancestor of all windows. In Figure 7.1, B is the ancestor A at the bottom and B at the top of the stacking order. That is why all of B is visible but portions
of B.l, but A is not, because A is not in the same branch as B.l. of A are obscured by B. By changing the stacking order of the root window's children, the user can
decide which application's window is fully visible on the'screen. The user manipulates the stacking
order through the window manager, which does the job by calling Xlib functions, such as
XCirculateSubWindows, XRaiseWindow, XLowerWindow,andXRest ackWindow.
The dimensions of windows and the units of the coordinate systems are specified in pixels, but Xlib
has functions that enable you to get the width and height of the screen in millimeters
(XWidthMMOfScreen and XHeightMMOfScreen) as well as in pixels (XWidthOfScreen and
XHeightOfScreen). Using the information provided by these functions, you can convert back and
forth between pixels and millimeters.
Figure 7.2.
Coordinate system and
geometry of a window in X
Position of this
window in parent's
coordinates = (x.y)
X assumes that the coordinates are discrete and each coordinate lies at the center of a pixel. Thus,
the origin (0,0) is at the center of the pixel at the upper-left corner, inside the border (see
Figure 7.3).
} min_aspect, max_aspect;
int base_width, base_height; /* Window size and gravity */
int win_gravity; /* (see later in this chapter) */
XMapWindow(theDisplay, theMain); XSizeHints;
XFlush(theDisplay);
i1'(XGetWindowAttributes(theDisplay, theMain, &MainXWA) == 0) When setting up an XSizeHints structure, you need not specify all fields of the structure. The x, y,
{ width, height, min_width, and min_height are the most commonly specified fields. You set bits
fprintf (stderr, "Error getting attributes of Main. \n" ); in flags to indicate the fields being specified. You can do this by setting flags to the bitwise-OR
exit (2) ;
of named constants defined in the header file <X11/ Xut il. h>. For example, to set the fields men-
} tioned above, flags is set to the bitwise-OR of the constants PPosition, PSize, and PMinSize.
/ * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . - . - . - - - - - - - - - - - - - -* / Here is how these fields are set in ini tapp:
void usage ()
{
fprintf (stderr, "%s [-display name] [-geometry geom]\n',
theAppName);
The P prefix in the names for the constants used to define the flags means that these are program-
Program-Specified Position and Size specified values.
You can use the convenience function XSetWMProperties to give the window manager several useful
hints and to inform it of the main window's preferred position and size. You specify the position
and size, or geometry, in an XSizeHints structure, which is defined in <X11/ Xutil. h> as the fol-
Xlib has many structures with several data fields for which not all fields need to be specified
lowing:
for a function. In such cases, the structure includes a flags field whose bits are used to
typedef struct indicate which of the other fields are set. You can set the flags field by bitwise-OR of
{
long flags; /* Indicates which fields are defined *(
constants that have been defined in the header file <x 11 / Xut il. h>. Each of these constants
int x, y; /* Suggested position and size */ ipdicate that cert~n fields in the structure have been specified. For example, in setting the
int width, height; /* for old window managers */ XS;i.zeHints structure, setting flags to (PPosi tion : PSize) indicates that values are
int min_width, min_height; /* Minimum width and height */
int max_width, max_height; /* Minimum width and height */
prQyidcd for the location (x, y) and size (width, height) fields.
int width_inc, height_inc; /* Width, height increments */
struct
{
int x; /* Numerator of aspect ratio */
int y; /* Denominator of aspect ratio */
selected font. If you want the user's specifications to remain as is, use 1 for both
arguments.
The user's choice of a window's position and size can come through the -geometry command-line
option or the geometry resource. If neither of these is specified, the program provides a default •. int xadd, yadd;
These are values to be added to the width and heighr, respectively. If you do not want any
geometry. The geometry is specified by a string of the form width x height + x + y, where
width and height are integers specifying size of window in pixels, and x and y indicate the posi- padding, provide 0s for these arguments.
tion in the parent's coordinate frame. (For more information about geometry, see Chapter 3.) The last four arguments are the addresses of the integers where XGeometry returns the
selected x, y, width, and height. In initapp, you accept the values directly in the
The user's specification of the geometry need not be complete; the string can have either the size or
the position alone. The programmer's problem is to have the application figure out what the user appropriate fields of the XSizeHints structure:
specifies and reconcile it with the default geometry. Xlib's XGeometry utiliry function is desigr:ted int bitmask;
to do the job; however, it requires the program's default geometry in a string. Handling user-
specified geometry requires the following steps:
/* Process the geometry specification */
1. Construct a string containing r~e default geometry:
bitmask = XGeometry(theDisplay, DefaultScreen(theDisplay),
char default_geometry[801; theGeom! default_geometry, DEFAULT_BDWIDTH,
1, 1, 0, 0, &(p_XSH->x), &(p_XSH->y),
&(p_XSH->width), &(p_XSH->height));
/* Construct a default geometry string */
sprintf(default_geometry, "%dx%d+%d+%d", p_XSH->width, /* Check bitmask and set flags in XSizeHints structure */
pJSH->height, p_XSH->x, p_XSH->y); if (bitmask & (XValue : YValue)) p_XSH->flags := USPosition;
2. Set the user-specified geometry string, stored in the string theGeom in initapp. "-- if (bitmask & (WidthValue : HeightValue))
3. Check whether the command-line or the resource file (.Xdefaults in the user's home
p_XSH->flags := USSize;
directory) provides a geometry string. If so, set the string theGeom to the user's definition The XGeometry function returns an integer value that should be viewed as a pattern of bits (a
of the geometry, giving precedence to the command-line option over the contents of the bi tmask). The set bits in the returned bi tmask indicate which of the x, y, width, and height vari-
resource file. This enables the user to override specifications in the resource file with ables were altered by XGeomet ry. As the previous code shows, if the position or size was altered
command-line options. The following example shows how initapp sets the user-defined because of a user-specified geometry, the flags field of the XSizeHints structure is modified to
geometry: indicate it. The constants named USPosition and USSize are bit patterns that tell the" window
theGeom = default_geometry; manager that these are user-specified options. Ideally, the window manager should use any user-
specified options as is, without any change. The exact behavior depends on the window manager.
/* Override the geometry, if necessary */
if(theGeom_cline != NULL) theGeom = theGeom_cline;
Standard Properties
else
if(theGeom_rsrc 1= NULL) theGeom = theGeom_rsrc; After you settle on a size for the main window, you can create it using XCreateSimpleWindow. This
4. Call XGeomet ry to get the position and size. The values come from the user-specified simple function requires the following arguments:
geometry, ~xcept where items ate missing in the user's specification. XGeometry takes the •. Display
display and screen as the first fWO arguments. For the screen argument, you can use the
•. Parent window's ID
Defaul tScreen macro. The default screen for the display theDisplay is
DefaultScreen (theDisplay). Next come fWO string arguments: the user-specified •. Window's location
geometry followed by the default geometry. The fifth argument is the border width in •. Window's size
pixels. The next four arguments are the following: •. Border width
•. unsigned int width_factor, height._ factor; •. Border color
The user-specified width and height are multiplied by these fWO factors. If you are
•. Background color
displaying text, these arguments can be the width and height of characters for the
In the case of the main window, the parent is the root window, which is identified by the macro if (XStringListToTextProperty(&theAppName, 1, &WName) == 0)
DefaultRootWindow(theDisplay). {
fprintf(stderr, "Error creating XTextPropertyl\n");
Creating the window does not show anything on the screen. The window appears only when you exit (1) ;
}
.map it-and before you map it, you have to inform the window manager about it. This enables the if(XStringListToTextProperty(&theAppName, 1, &IName) == 0)
window manager to intervene and place the window correctly when it is mapped. {
fprintf(stderr, "Error creating XTextPropertyl\n");
The convenience function, XSetWMProperties, is useful for this. As the name implies, you are set- exit('I);
}
ting the properties of a window (the one you just created). In X, a property is some data stored at the
/* Allocate and set up an XWMHints structure (see next section) */
server and tagged by a window ID. You can store a property in a window and restore it. The inter-
pretation of the data represented by a property depends on the applications that use it. Properties
are used for exchanging information among X applications-an example being the communica-
xSetWMProperties(theDisplay, theMain, &WName, &IName, argv, argc,
tion between your application and the window manager. p_XSH, p_XWMH, p_CH);
The arguments to XSetWMProperties are the following: XSetWMProperties combines the functionality of several Xlib functions. You can set the window's
•. Display in which your application's windows are located name and its icon's name using the functions XSetWMName and XSetWMIconName,respectively. Xlib
provides XSetCommandfor storing the command-lineparamet~rs as a property o~ a window. You
•. Window for which you are setting the properties
can use XSetWMNormalHints to provide the size hints to the wmdow manager. Fmally, you could
•. XTextProperty, representing the window's name (use XStringListToTextProperty use XSetWMHints and XSetClassHint to transmit the information in XWMHintsand ~ClassHint
function to convert a string to XTextProperty) structures to the X server. If you use these functions instead ofXSetWMProperties, this is the equiva-
•. XTextProperty, representing the name to be displayed in the window's icon lent sequence of calls:
•. Command-line arguments used in starting the application xClassHint *p_CH;
XWMHints *p_XWMH;
•. Number of command-line arguments xSizeHints *p_XSH;
•. Pointer to the XSizeHints srructure that holds the preferred geometry of the window XTextProperty 'WName;
XTextProperty IName;
•. Pointer'to the XWMHintsstructure holding additional hints for the window manager /* Allocate and initialize the hint structures */
(explained in the next section)
•. Pointer to the XClassHint structure specifYing the application's name and its class name
xSetWMName(theDisplay, theMain, &WName);
In ini tapp, the following code accomplishes the creation of the main window and the setting of xSetlconName(theDisplay, theMain, &IName);
the window manager properties: xSetCommand(theDisplay, theMain, argv, argc);
XSetWMNormalHints(theDisplay, theMain, p_XSH)j
/* Create the main window using the position and size xSetWMHints(theDisplay, theMain, p_XWMH);
* information derived above. For border color, use the xSetClassHint(theDisplay, theMain, p_CH);
* foreground color.
*/
theMain = xcreateSimpleWindow(theDisplay,
DefaultRootWindow(theDisplay),
p_XSH·>x, p_XSH->y, P_XSH->width, P_XSH->height,
DEFAULT_BDWIDTH, theFGpix, theBGpix)j