The fundamental abstraction and data type of the X Toolkit is the widget, which is a combination of an X window and its associated input and display semantics and which is dynamically allocated and contains state information. Some widgets display information (for example, text or graphics), and others are merely containers for other widgets (for example, a menu box). Some widgets are output-only and do not react to pointer or keyboard input, and others change their display in response to input and can invoke functions that an application has attached to them.
Every widget belongs to exactly one widget class, which is statically allocated and initialized and which contains the operations allowable on widgets of that class. Logically, a widget class is the procedures and data associated with all widgets belonging to that class. These procedures and data can be inherited by subclasses. Physically, a widget class is a pointer to a structure. The contents of this structure are constant for all widgets of the widget class but will vary from class to class. (Here, ``constant'' means the class structure is initialized at compile time and never changed, except for a one- time class initialization and in-place compilation of resource lists, which takes place when the first widget of the class or subclass is created.)
The distribution of the declarations and code for a new
widget class among a public .h file for application programmer
use, a private .h file for widget programmer use, and the
implementation .c file. The predefined widget classes adhere to
these conventions.
A widget instance is composed of two parts:
A data structure which contains instance-specific values.
A class structure which contains information that is applicable to
all widgets of that class.
The Core widget class contains the definitions of fields common to all widgets. All widgets classes are subclasses of the Core class, which is defined by the CoreClassPart and CorePart structures.
All widget classes contain the fields defined in the CoreClassPart structure (see over page).
All widget classes have the Core class fields as their
first component. The prototypical WidgetClass and
CoreWidgetClass are defined with only this set of fields.
Various routines can cast widget class pointers, as needed, to specific widget class types.
typedef struct {
CoreClassPart core_class;
} WidgetClassRec, *WidgetClass, CoreClassRec, *CoreWidgetClass;
typedef struct {
WidgetClass superclass;
String class_name;
Cardinal widget_size;
XtProc class_initialize;
XtWidgetClassProc class_part_initialize;
XtEnum class_inited;
XtInitProc initialize;
XtArgsProc initialize_hook;
XtRealizeProc realize;
XtActionList actions;
Cardinal num_actions;
XtResourceList resources;
Cardinal num_resources;
XrmClass xrm_class;
Boolean compress_motion;
XtEnum compress_exposure;
Boolean compress_enterleave;
Boolean visible_interest;
XtWidgetProc destroy;
XtWidgetProc resize;
XtExposeProc expose;
XtSetValuesFunc set_values;
XtArgsFunc set_values_hook;
XtAlmostProc set_values_almost;
XtArgsProc get_values_hook;
XtAcceptFocusProc accept_focus;
XtVersionType version;
XtPointer callback_private;
String tm_table;
XtGeometryHandler query_geometry;
XtStringProc display_accelerator;
XtPointer extension;
} CoreClassPart;
In Intrinsic.h:
extern WidgetClassRec widgetClassRec;
#define coreClassRec widgetClassRec
The opaque types Widget and WidgetClass and the opaque variable widgetClass are defined for generic actions on widgets. In order to make these types opaque and ensure that the compiler does not allow applications to access private data, the Intrinsics use incomplete structure definitions in Intrinsic.h:
extern WidgetClass widgetClass, coreWidgetClass;
typedef struct _WidgetClassRec *WidgetClass, *CoreWidgetClass;
All widget instances contain the fields defined in the CorePart structure.
typedef struct _CorePart {
Widget self;
WidgetClass widget_class;
Widget parent;
Boolean being_destroyed;
XtCallbackList destroy_callbacks;
XtPointer constraints;
Position x;
Position y;
Dimension width;
Dimension height;
Dimension border_width;
Boolean managed;
Boolean sensitive;
Boolean ancestor_sensitive;
XtTranslations accelerators;
Pixel border_pixel;
Pixmap border_pixmap;
WidgetList popup_list;
Cardinal num_popups;
String name;
Screen *screen;
Colormap colormap;
Window window;
Cardinal depth;
Pixel background_pixel;
Pixmap background_pixmap;
Boolean visible;
Boolean mapped_when_managed;
} CorePart;
In order to make these types opaque and ensure that the compiler does not allow applications to access private data, the Intrinsics use incomplete structure definitions in Intrinsic.h.
typedef struct {
CorePart core;
} WidgetRec, *Widget, CoreRec, *CoreWidget;
typedef struct _WidgetRec *Widget, *CoreWidget;
The resource names, classes, and representation types specified in the coreClassRec resource list are
|
Additional resources are defined for all widgets via the objectClassRec and rectObjClassRec resource lists.
The default values for the Core fields, which are filled in from the resource lists and by the initialize procedures, are
|
XtUnspecifiedPixmap is a symbolic constant guaranteed to be unequal to any valid Pixmap id, None, and ParentRelative.
The Composite widget class is a subclass of the Core widget class. Composite widgets are intended to be containers for other widgets. The additional data used by composite widgets are defined by the CompositeClassPart and CompositePart structures.
In addition to the Core class fields, widgets of the Composite class have the following class fields.
typedef struct {
XtGeometryHandler geometry_manager;
XtWidgetProc change_managed;
XtWidgetProc insert_child;
XtWidgetProc delete_child;
XtPointer extension;
} CompositeClassPart;
typedef struct {
XtPointer next_extension;
XrmQuark record_type;
long version;
Cardinal record_size;
Boolean accepts_objects;
} CompositeClassExtensionRec, *CompositeClassExtension;
The single occurrences of the class record and pointer for creating instances of Composite are
typedef struct {
CoreClassPart core_class;
CompositeClassPart composite_class;
} CompositeClassRec, *CompositeWidgetClass;
In IntrinsicP.h:
In Intrinsic.h:
extern CompositeClassRec compositeClassRec;
The opaque types CompositeWidget and CompositeWidgetClass and the opaque variable compositeWidgetClass are defined for generic operations on widgets whose class is Composite or a subclass of Composite. The symbolic constant for the CompositeClassExtension version identifier is XtCompositeExtensionVersion Intrinsic.h uses an incomplete structure definition to ensure that the compiler catches attempts to access private data.
extern WidgetClass compositeWidgetClass;
typedef struct _CompositeClassRec *CompositeWidgetClass;
In addition to the Core instance fields, widgets of the Composite class have the following instance fields defined in the CompositePart structure.
typedef struct {
WidgetList children;
Cardinal num_children;
Cardinal num_slots;
XtOrderProc insert_position;
} CompositePart;
Intrinsic.h uses an incomplete structure definition to ensure that the compiler catches attempts to access private data.
typedef struct {
CorePart core;
CompositePart composite;
} CompositeRec, *CompositeWidget;
typedef struct _CompositeRec *CompositeWidget;
The resource names, classes, and representation types that are specified in the compositeClassRec resource list are
|
The default values for the Composite fields, which are filled in from the Composite resource list and by the Composite initialize procedure, are
|
The children, num_children, and insert_position fields are declared as resources; XtNinsertPosition is a settable resource, XtNchildren and XtNnumChildren may be read by any client but should only be modified by the composite widget class procedures.
The Constraint widget class is a subclass of the Composite widget class. Constraint widgets maintain additional state data for each child; for example, client-defined constraints on the child's geometry. The additional data used by constraint widgets are defined by the ConstraintClassPart and ConstraintPart structures.
In addition to the Core and Composite class fields, Constraint widgets have the following class fields:
typedef struct {
XtResourceList resources;
Cardinal num_resources;
Cardinal constraint_size;
XtInitProc initialize;
XtWidgetProc destroy;
XtSetValuesFunc set_values;
XtPointer extension;
} ConstraintClassPart;
typedef struct {
XtPointer next_extension;
XrmQuark record_type;
long version;
Cardinal record_size;
XtArgsProc get_values_hook;
} ConstraintClassExtensionRec, *ConstraintClassExtension;
The single occurrences of the class record and pointer for creating instances of Constraint are
typedef struct _ConstraintClassRec {
CoreClassPart core_class;
CompositeClassPart composite_class;
ConstraintClassPart constraint_class;
} ConstraintClassRec, *ConstraintWidgetClass;
In Intrinsic.h:
extern ConstraintClassRec constraintClassRec;
The opaque types ConstraintWidget and ConstraintWidgetClass and the opaque variable constraintWidgetClass are defined for generic operations on widgets whose class is Constraint or a subclass of Constraint. The symbolic constant for the ConstraintClassExtension version identifier is XtConstraintExtensionVersion Intrinsic.h uses an incomplete structure definition to ensure that the compiler catches attempts to access private data.
extern WidgetClass constraintWidgetClass;
typedef struct _ConstraintClassRec *ConstraintWidgetClass;
In addition to the Core and Composite instance fields,
widgets of the Constraint class have the following unused
instance fields defined in the ConstraintPart structure
Constraint widgets have the Constraint instance fields immediately following the Composite instance fields.
typedef struct { int empty; } ConstraintPart;
Intrinsic.h uses an incomplete structure definition to ensure that the compiler catches attempts to access private data.
typedef struct {
CorePart core;
CompositePart composite;
ConstraintPart constraint;
} ConstraintRec, *ConstraintWidget;
typedef struct _ConstraintRec *ConstraintWidget;
The constraintClassRec core_class and constraint_class resources fields are NULL and the num_resources fields are zero; no additional resources beyond those declared by the superclasses are defined for Constraint.