Museum

Home

Lab Overview

Retrotechnology Articles

⇒ Online Manual

Media Vault

Software Library

Restoration Projects

Artifacts Sought

POPUPWINDOW WIDGET(3W)  —  OLIT

WIDGET CLASS NAME

PopupWindowShell

SYNOPSIS

#include <Intrinsic.h>
#include <StringDefs.h>
#include <OpenLook.h>
#include <PopupWindo.h>

static void
Apply (w,client_data,call_data)
Widget w;
XtPointer client_data, call_data;
{
printf ("Apply callback!\n");
}
 Arg args[3];
Widget popupwindow, w;
Widget uppercontrol, lowercontrol, footer;
 static XtCallbackRec applycalls[] = {
{ Apply, NULL },
{ NULL, NULL },
};
 XtSetArg(args[0], XtNapply, (XtArgVal) applycalls);
 popupwindow = XtCreatePopupShell("PopupShell",
popupWindowShellWidgetClass,
controlparent, args, 1);
 XtSetArg(args[0], XtNupperControlArea, &uppercontrol);
XtSetArg(args[1], XtNlowerControlArea, &lowercontrol);
XtSetArg(args[2], XtNfooterPanel, &footer);
 XtGetValues(popupshell, args, 3);

w = XtCreateWidget(name, widget-class, upper_controlarea, ...);
w = XtCreateWidget(name, widget-class, lower_controlarea, ...);
w = XtCreateWidget(name, widget-class, footerarea, ...);
.
.
.
XtPopup(popupwindow, XtGrabNone);

DESCRIPTION

Controls not Automatically Related to Selected Objects

The PopupWindow widget can be used to implement the OPEN LOOK property window.  It manages the creation of a property window and provides a simple interface for populating the window with controls.  However, it has no innate semantics to relate the controls with a selected object; this must be handled by the application.  For example, the application must dim all the controls if an object selected by the end user is incompatible with a displayed property window.  PopupWindow Components

The PopupWindow widget has the following parts:

—Upper Control Area

—Lower Control Area

—Window Border

—Popup Window Menu

—Settings Menu (Conditional)

—Apply Button (Conditional)

—Reset Button (Conditional)

—Reset to Factory Button (Conditional)

—Set Defaults Button (Conditional)

—Header

—Window Mark

—Pushpin (Optional)

—Resize Corners (Optional)

—Footer (Optional)

The Window Border, Popup Window Menu, Header, Window Mark, and Pushpin provide the end user with window management controls over the PopupWindow widget.  The Apply, Reset, Reset to Factory, and Set Defaults Buttons are automatically created, if needed, to help create a standard layout of a property window.  The application controls which of these, if any, appear in the pop-up window.  Automatic Addition of Buttons, Settings Menu

To aid in the creation of a property window, the PopupWindow has several callbacks typically used in such a pop-up window, for applying, resetting, etc.  For each of these callbacks that the application sets in the argument list used for creation of the PopupWindow, the PopupWindow widget automatically creates a button in the Lower Control Area, and the same button in the Settings Menu.  If none of the callbacks are defined, no buttons are automatically created and no Settings Menu is created. 

If the application is building a command window, it has to create whatever buttons and menus are needed. 
Sub-class of the Shell Widget

The PopupWindow widget is a sub-class of the Shell widget.  Therefore, as the SYNOPSIS shows, the XtCreatePopupShell() routine is used to create a pop-up window instead of the normal XtCreateWidget().  Popping the Pop-up Window Up/Down

The application controls when the PopupWindow widget is to be displayed, or popped up.  As indicated in the SYNOPSIS, the XtPopup() routine can be used for this. 

The application also has the responsibility for raising a mapped pop-up window to the front if the user attempts to pop it up and it’s already up.  This can be accomplished using the XRaiseWindow function. 

However, the application cannot control when the PopupWindow widget is to be popped down, since the end user may have pinned it up with the intent that it stays up until he or she dismisses it.  The widget itself detects when to pop down: the end user clicks SELECT on an OblongButton widget in the Lower Control Area, or the end user dismisses the pop-up window using the Popup Window Menu or pushpin.  Upper and Lower Control Areas

The Upper and Lower Control Areas are handled by separate widget interfaces.  The SYNOPSIS shows how the widget IDs of the control areas (upper_controlarea and lower_controlarea) and footer container (footerarea) are obtained from the PopupWindow widget. 

The two Control Areas and the Footer abut so that there is no space between them.  An application can control the distance between the controls in the Control Areas by setting margins in each area. 

If the PopupWindow widget automatically creates the Apply, Reset, Reset to Factory, or Set Defaults Buttons, it puts them in that order in the Lower Control Area.  No space is left for a missing button.  These buttons will also appear before any buttons added to the Lower Control Area by the application. 
PopupWindow Coloration

the diagram Popup Window Coloration illustrates the resources that affect the coloration of the PopupWindow widget. 

SUBSTRUCTURE

Lower Control Area and Upper Control Area components

Names: lowercontrolarea, uppercontrolarea
Class: ControlArea

The following resources are directed to both Control Area components.  To set different values for the same resources in the different Control Areas, the application must access the resources using the appropriate Control Area widget IDs. 
Application Resources (cont.)
            Name       Type   Default  Access XtNalignCaptions    Boolean      †       I
       XtNcenter    Boolean     FALSE       I
         XtNhPad  Dimension         4       I
       XtNhSpace  Dimension         4       I
   XtNlayoutType   OlDefine      ‡       I
      XtNmeasure        int         1       I
     XtNuserData  XtPointer      NULL     SGI
         XtNvPad  Dimension         4       I
       XtNvSpace  Dimension         4       I

†The default is TRUE for the Upper Control Area and FALSE for the Lower Control Area. 

‡The default is OL_FIXEDCOLS for the Upper Control Area and OL_FIXEDROWS for the Lower Control Area. 

Footer

Names: footerpanel
Class: FooterPanel

RESOURCES

PopupWindow Resource Set
                   Name                    Type     Default   Access
    XtNallowShellResize                 Boolean        TRUE      SGI
   XtNancestorSensitive                 Boolean        TRUE       G∗
               XtNapply          XtCallbackList        NULL        I
          XtNbackground                   Pixel       White  SGI†
    XtNbackgroundPixmap                  Pixmap      (none)  SGI†
         XtNborderColor                   Pixel       Black  SGI†
        XtNborderPixmap                  Pixmap      (none)  SGI†
         XtNborderWidth               Dimension           0      SGI XtNcreatePopupChildProc  XtCreatePopupChildProc        NULL      SGI
               XtNdepth                     int  (parent’s)       GI
     XtNdestroyCallback          XtCallbackList        NULL       SI
         XtNfooterPanel                  Widget      (none)        G
            XtNgeometry                  String        NULL       GI PopupWindow Resource Set (cont.)
               Name            Type       Default  Access
          XtNheight       Dimension  (calculated)     SGI
       XtNheightInc             int            -1     SGI
           XtNinput         Boolean         FALSE       G XtNlowerControlArea          Widget        (none)       G
      XtNmaxAspectX        Position            -1     SGI
      XtNmaxAspectY        Position            -1     SGI
      XtNminAspectX        Position            -1     SGI
      XtNminAspectY        Position            -1     SGI
 XtNpopdownCallback  XtCallbackList          NULL      SI
   XtNpopupCallback  XtCallbackList          NULL      SI
           XtNreset  XtCallbackList          NULL       I
    XtNresetFactory  XtCallbackList          NULL       I
       XtNsaveUnder         Boolean         FALSE     SGI
       XtNsensitive         Boolean          TRUE     GI∗
     XtNsetDefaults  XtCallbackList          NULL       I
           XtNtitle          String          NULL     SGI XtNupperControlArea          Widget        (none)       G
        XtNuserData       XtPointer          NULL     SGI
          XtNverify  XtCallbackList          NULL       I
           XtNwidth        Position  (calculated)     SGI
        XtNwidthInc        Position            -1     SGI
               XtNx        Position             0     SGI
               XtNy        Position             0     SGI
XtNapply
XtNreset
XtNresetFactory
XtNsetDefaults

Each of these resources is a callback list that corresponds to a button in the Lower Control Area and in the Settings Menu.  Typically, an application defines one of these resources only when it is using the PopupWindow widget for a property window.  For each resource with a defined callback, a unique button is added in the Lower Control Area; conversely, where a resource has no callback defined by the application, no button is shown.  The callbacks must be set at initialization time in order for the buttons to be created.  The labels for these buttons are listed below, in the order they appear in the Lower Control Area
  ResourceButton Name
 
XtNapplyApply XtNresetReset XtNresetFactoryReset to Factory XtNsetDefaults Set Defaults No space is left for a missing button.

In general, the callback list for one of these resources is issued when the user activates the button associated with the resource.  After the callbacks are issued, the PopupWindow widget will attempt to pop itself down, first checking with the application that this may be done by issuing the XtNverify callbacks, then checking the state of the pushpin.  XtNfooterPanel

This is the widget ID of the FooterPanel class composite child widget that handles the Footer; its value is available once the PopupWindow widget has been created.  If the application wants a footer, it can add one to the composite identified by this resource.  XtNlowerControlArea
XtNupperControlArea

These are the widget IDs of the ControlArea class composite child widgets that handle the Lower Control Area and Upper Control Area, respectively.  The application can use each widget ID to populate the PopupWindow with controls.  These widget IDs are available once the PopupWindow widget has been created. 

Any widgets of the class OblongButton added to the Lower Control Area are assumed to be window disposition controls; that is, when the end user activates one of them the PopupWindow widget should pop itself down, if allowed by the application and the state of the pushpin.  XtNverify

This resource defines the callbacks to be invoked when the PopupWindow attempts to pop itself down.  The call_data parameter is a pointer to a variable of type Boolean.  It is initially set to TRUE, and the application should set a value that reflects whether the pop-down is allowed.  Typically, the application will use this to prevent a pop-down so that an error message can be displayed. 

Since more than one callback routine may be registered for this resource, each callback routine can first check the value pointed to by the call_data parameter to see if a previous callback in the list has already rejected the pop-down attempt.  If one has, the subsequent callback need not continue evaluating whether a pop-down is allowed.  If the value is still TRUE after the last callback returns, the pop-down continues. 

Since these callbacks are issued before the PopupWindow checks the state of the pushpin, the application should not assume that the pop-down will occur even though it has allowed it. 

Sun Release 4.0  —  Last change: 1/8/90

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026