Creating and Managing Windows

This section discusses the following aspects of window management:

• Opening and Closing Windows
• Setting Window Attributes and Constraints
• Controlling Window Placement
• Changing Windows Noninteractively
• Managing Multiple Windows
• Other Window Subroutines

GL provides subroutines to create and manipulate windows from an application program. The windowing subroutines are implemented on top of Enhanced X-Windows and work with any window manager, including the AIXwindows window manager. A GL window is one in which a GL application draws an image, while a text window runs a shell.

List of GL Window Subroutines

Opening and Closing Windows

The GL subroutines for opening and closing windows are the winopen, swinopen, and winclose subroutines. (The swinopen subroutine creates subwindows from a parent window.) Exiting a program causes any existing windows to close automatically.

Setting Window Attributes and Constraints

You can control the size, location, and shape of windows from a GL client program. Calling the winopen subroutine without specifying any of these characteristics allows you to open a window of any size or shape anywhere on the screen. You can, however, open a specific window, such as a small square with a border, if you specify the desired size and shape.

Use the window constraint subroutines in the following table to specify window characteristics. Call these subroutines before opening a window with the winopen subroutine. GL applies these constraints when it opens the window.

To respecify constraints for a window that is already open, first call the desired series of window constraint subroutines from the previous table, then call the winconstraints subroutine.

When a user interactively changes a window, the window constraints are automatically enforced. Interactively changing a window means using the mouse and keyboard, in cooperation with the currently running window manager, to move, resize, or reshape a window.

The window constraints allow the applications programmer to control and limit how the user resizes and reshapes a window. The maxsize subroutine prevents a user from resizing a window to any size larger than the size set by the subroutine parameters. Likewise, the minsize subroutine prevents the user from shrinking a window below the specified size.

The keepaspect subroutine prevents a user from resizing a window so that the aspect ratio is changed. The stepunit subroutine allows the window to be resized only in specified discrete steps. Normally, a window can be resized by arbitrary amounts; in other words, the stepunit subroutine usually specifies one pixel.

The prefsize and prefposition subroutines constrain the size and position of the window. The prefsize subroutine prevents a user from resizing the window. The prefposition subroutine prevents a user from moving the window. To place a window on the screen in some position, allowing the user afterwards to reposition or resize the window, call the winconstraints subroutine after the winopen subroutine (or call the winconstraints subroutine twice in a row.) The winconstraints subroutine clears previous constraints and sets any new ones.

Controlling Window Placement

Ultimately, window placement is controlled by the window manager. The default window manager for your system is the AIXwindows window manager. To control the behavior of this window manager regarding interpretation and placement, edit the .Xdefaults file in the user's home directory.

In controlling interpretation of the prefposition subroutine parameters, if you add the following line to the .Xdefaults file:

Mwm*positionIsFrame: True

the location of the window is assumed to include the boundary of the window. That is, the screen coordinates are assumed to refer to the lower left-hand corner of the window border. In contrast, if you add the following line to the .Xdefaults file:

Mwm*positionIsFrame: False

the window manager interprets the position as the location of the window's interior, ignoring the window border.

The AIXwindows window manager normally places a window so that it is fully visible on the screen. To open a window partly or wholly off the screen, add the following line to the .Xdefaults file:

Mwm*positionOnScreen: False

Changing the line to read:

Mwm*positionOnScreen: True

makes the window manager ignore the values specified with the prefposition subroutine and place the window so that it is fully visible on the screen.

In controlling placement of a window, if you add the following line to the .Xdefaults file:

Mwm*interactivePlacement: True

a rubber-banded window appears when the winopen subroutine is executed. The user can place the window where desired on the screen. If you change the line to read:

Mwm*interactivePlacement: False

the window is immediately placed on the screen in the specified position when the winopen subroutine is executed.

The AIXwindows window manager normally adds an offset to the location of every new window that is opened. This offset is used to keep new windows from piling up at one place. The offset spreads windows evenly over the entire screen. To turn off this behavior, specify

Mwm*clientAutoPlace: False

When clientAutoPlace is turned off, GL windows are mapped on the screen exactly at the location specified with the prefposition subroutine.

Changing Windows Noninteractively

The applications programmer can have the same control over windows that an applications user can. A window may be moved, resized, raised, and lowered from the applications program with the subroutines in the following table:

GL performs these operations on the current window, which is set with the winset subroutine.

Managing Multiple Windows

Multiple GL windows opened by the same process do not normally share attributes. Every window has its own current color; its own transformation matrix stack; and its own viewport stack, name stack, and attribute stack (which contains attributes such as the current linestyle and linewidth). The action of subroutines such as swapbuffers, RGBmode, depthcue, and lmbind is limited to the current window.

The only exceptions to this rule are a few window management subroutines (such as the winset subroutine) and the def subroutines: deflinestyle, defpattern, defrasterfont, loadXfont, lmdef, and makeobj. If a linestyle, pattern, light, font, or object is defined for one window, it becomes available to all windows opened by the same process. These definitions are referenced by the same index in all such windows. Information is never shared between different processes. The previous comments apply only to windows opened by one and the same process.

The exception made for the def subroutines is provided as a convenience to the user. If a linestyle has been defined in one window, and the user wants to use it in another, the definition should not have to be respecified in other, possibly numerous, windows. In addition, the def subroutine exception allows the system to operate in a more efficient manner. The system does not need to keep track of multiple copies of duplicate information.

Other than these shared definitions, all other attributes that are part of GL have been made deliberately nonsharable across windows. True multiple, independent drawing sessions can therefore be performed in multiple windows. Separate windows do not interfere with one another, and the applications writer does not have to engage in complicated window attribute management. The system maintains the attribute management automatically.

Other Window Subroutines

GL provides other subroutines to control the windows, as shown in the following table: