Table of Contents
Although widget writers are free to treat Core as the base class of the widget hierarchy, there are actually three classes above it. These classes are Object, RectObj (Rectangle Object), and (unnamed), and members of these classes are referred to generically as objects. By convention, the term widget refers only to objects that are a subclass of Core, and the term nonwidget refers to objects that are not a subclass of Core. In the preceding portion of this specification, the interface descriptions indicate explicitly whether the generic widget argument is restricted to particular subclasses of Object. Sections 12.2.5, 12.3.5, and 12.5 summarize the permissible classes of the arguments to, and return values from, each of the Intrinsics routines.
In order not to conflict with previous widget code, the data structures used by nonwidget objects do not follow all the same conventions as those for widgets. In particular, the class records are not composed of parts but instead are complete data structures with filler for the widget fields they do not use. This allows the static class initializers for existing widgets to remain unchanged.
The
Object
object contains the definitions of fields common to all
objects. It encapsulates the mechanisms for resource management.
All objects and widgets are members of subclasses of
Object,
which is defined by the
ObjectClassPart
and
ObjectPart
structures.
The common fields for all object classes are defined in the
ObjectClassPart
structure. All fields have the same purpose,
function, and restrictions as the corresponding fields in
CoreClassPart
;
fields whose
names are objn for some integer n are not
used for Object,
but exist to pad the data structure so that it matches Core's class
record. The class record initialization must fill all
objn fields with NULL or zero as appropriate to the type.
typedef struct _ObjectClassPart {
WidgetClass superclass;
String class_name;
Cardinal widget_size;
XtProc class_initialize;
XtWidgetClassProc class_part_initialize;
XtEnum class_inited;
XtInitProc initialize;
XtArgsProc initialize_hook;
XtProc obj1;
XtPointer obj2;
Cardinal obj3;
XtResourceList resources;
Cardinal num_resources;
XrmClass xrm_class;
Boolean obj4;
XtEnum obj5;
Boolean obj6;
Boolean obj7;
XtWidgetProc destroy;
XtProc obj8;
XtProc obj9;
XtSetValuesFunc set_values;
XtArgsFunc set_values_hook;
XtProc obj10;
XtArgsProc get_values_hook;
XtProc obj11;
XtVersionType version;
XtPointer callback_private;
String obj12;
XtProc obj13;
XtProc obj14;
XtPointer extension;
} ObjectClassPart;
The extension record defined for
ObjectClassPart
with a record_type equal to
NULLQUARK
is
ObjectClassExtensionRec
.
typedef struct {
XtPointer next_extension; See the section called “Class Extension Records”
XrmQuark record_type; See the section called “Class Extension Records”
long version; See the section called “Class Extension Records”
Cardinal record_size; See the section called “Class Extension Records”
XtAllocateProc allocate; See the section called “Widget Instance Allocation: The allocate Procedure”.
XtDeallocateProc deallocate; See the section called “Widget Instance Deallocation: The deallocate Procedure”.
} ObjectClassExtensionRec, *ObjectClassExtension;
The prototypical
ObjectClass
consists of just the
ObjectClassPart
.
typedef struct _ObjectClassRec {
ObjectClassPart object_class;
} ObjectClassRec, *ObjectClass;
The predefined class record and pointer for
ObjectClassRec
are
In
IntrinsicP.h
:
extern ObjectClassRec objectClassRec;
In
Intrinsic.h
:
extern WidgetClass objectClass;
The opaque types
Object
and
ObjectClass
and the opaque variable
objectClass
are defined for generic actions on objects.
The symbolic constant for the
ObjectClassExtension
version identifier is
XtObjectExtensionVersion
(see the section called “Class Extension Records”).
Intrinsic.h
uses an incomplete structure definition to ensure that the
compiler catches attempts to access private data:
typedef struct _ObjectClassRec* ObjectClass;
The common fields for all object instances are defined in the
ObjectPart
structure. All fields have the same meaning as the
corresponding fields in
CorePart
.
typedef struct _ObjectPart {
Widget self;
WidgetClass widget_class;
Widget parent;
Boolean being_destroyed;
XtCallbackList destroy_callbacks;
XtPointer constraints;
} ObjectPart;
All object instances have the
Object
fields as their first component. The prototypical type
Object
is defined with only this set of fields.
Various routines can cast object pointers, as needed, to specific
object types.
In
IntrinsicP.h
:
typedef struct _ObjectRec {
ObjectPart object;
} ObjectRec, *Object;
In
Intrinsic.h
:
typedef struct _ObjectRec *Object;
The resource names, classes, and representation types specified in the
objectClassRec
resource list are:
Name | Class | Representation |
---|---|---|
XtNdestroyCallback | XtCCallback | XtRCallback |
All fields in
ObjectPart
have the same default values as the corresponding fields in
CorePart
.
The WidgetClass arguments to the following procedures may be
objectClass
or any subclass:
XtInitializeWidgetClass, XtCreateWidget, XtVaCreateWidget XtIsSubclass, XtCheckSubclass XtGetResourceList, XtGetConstraintResourceList
The Widget arguments to the following procedures may be of class Object or any subclass:
XtAddCallback
,XtAddCallbacks
,XtRemoveCallback
,XtRemoveCallbacks
,XtRemoveAllCallbacks
,XtCallCallbacks
,XtHasCallbacks
,XtCallCallbackList
XtClass
,XtSuperclass
,XtIsSubclass
,XtCheckSubclass
,XtIsObject
,XtIsRectObj
,XtIsWidget
,XtIsComposite
,XtIsConstraint
,XtIsShell
,XtIsOverrideShell
,XtIsWMShell
,XtIsVendorShell
,XtIsTransientShell
,XtIsToplevelShell
,XtIsApplicationShell
,XtIsSessionShell
XtIsManaged
,XtIsSensitive
(both will returnFalse
if argument is not a subclass of RectObj)XtIsRealized
(returns the state of the nearest windowed ancestor if class of argument is not a subclass of Core)XtParent
,*XtDisplayOfObject
,*XtScreenOfObject
,XtWindowOfObject
XtSetKeyboardFocus
(descendant)XtGetSubresources
,XtGetApplicationResources
,XtVaGetSubresources
,XtVaGetApplicationResources
The return value of the following procedures will be of class Object or a subclass:
XtParent
The return value of the following procedures will be
objectClass
or a subclass:
XtClass
,XtSuperclass
The Object class exists to enable programmers to use the Intrinsics' classing and resource-handling mechanisms for things smaller and simpler than widgets. Objects make obsolete many common uses of subresources as described in Sections 9.4, 9.7.2.4, and 9.7.2.5.
Composite
widget classes that wish to accept nonwidget children must
set the accepts_objects field in the
CompositeClassExtension
structure to
True
.
XtCreateWidget
will otherwise generate an error message on an attempt to create a
nonwidget child.
Of the classes defined by the Intrinsics,
ApplicationShell
and
SessionShell
accept nonwidget children, and the class of any nonwidget child
must not be
rectObjClass
or any subclass. The intent of allowing
Object
children of
ApplicationShell
and
SessionShell
is to provide clients a simple mechanism
for establishing the resource-naming root of an object hierarchy.
The class of rectangle objects is a subclass of
Object
that represents
rectangular areas. It encapsulates the mechanisms for geometry
management and is called RectObj
to avoid conflict with the Xlib
Rectangle
data type.
As with the
ObjectClassPart
structure, all fields in the
RectObjClassPart
structure have the same
purpose and function as the corresponding fields in
CoreClassPart
;
fields whose names are rectn for some integer
n are not used for
RectObj, but exist to pad the data structure so that it matches
Core's
class record. The class record initialization must fill all
rectn fields with NULL or zero as appropriate to the type.
typedef struct _RectObjClassPart {
WidgetClass superclass;
String class_name;
Cardinal widget_size;
XtProc class_initialize;
XtWidgetClassProc class_part_initialize;
XtEnum class_inited;
XtInitProc initialize;
XtArgsProc initialize_hook;
XtProc rect1;
XtPointer rect2;
Cardinal rect3;
XtResourceList resources;
Cardinal num_resources;
XrmClass xrm_class;
Boolean rect4;
XtEnum rect5;
Boolean rect6;
Boolean rect7;
XtWidgetProc destroy;
XtWidgetProc resize;
XtExposeProc expose;
XtSetValuesFunc set_values;
XtArgsFunc set_values_hook;
XtAlmostProc set_values_almost;
XtArgsProc get_values_hook;
XtProc rect9;
XtVersionType version;
XtPointer callback_private;
String rect10;
XtGeometryHandler query_geometry;
XtProc rect11;
XtPointer extension ;
} RectObjClassPart;
The
RectObj
class record consists of just the
RectObjClassPart
.
typedef struct _RectObjClassRec {
RectObjClassPart rect_class;
} RectObjClassRec, *RectObjClass;
The predefined class record and pointer for
RectObjClassRec
are
In
Intrinsic.h
:
extern RectObjClassRec rectObjClassRec;
In
Intrinsic.h
:
extern WidgetClass rectObjClass;
The opaque types
RectObj
and
RectObjClass
and the opaque variable
rectObjClass
are defined for generic actions on objects
whose class is RectObj or a subclass of
RectObj.
Intrinsic.h
uses an incomplete structure definition to ensure that the compiler
catches attempts to access private data:
typedef struct _RectObjClassRec* RectObjClass;
In addition to the
ObjectPart
fields,
RectObj
objects have the following fields defined in the
RectObjPart
structure. All fields have the same meaning as the corresponding field in
CorePart
.
typedef struct _RectObjPart {
Position x, y;
Dimension width, height;
Dimension border_width;
Boolean managed;
Boolean sensitive;
Boolean ancestor_sensitive;
} RectObjPart;
RectObj objects have the RectObj fields immediately following the Object fields.
typedef struct _RectObjRec {
ObjectPart object;
RectObjPart rectangle;
} RectObjRec, *RectObj;
In
Intrinsic.h
:
typedef struct _RectObjRec* RectObj;
The resource names, classes, and representation types that are specified in the
rectObjClassRec
resource list are:
Name | Class | Representation |
---|---|---|
XtNancestorSensitive | XtCSensitive | XtRBoolean |
XtNborderWidth | XtCBorderWidth | XtRDimension |
XtNheight | XtCHeight | XtRDimension |
XtNsensitive | XtCSensitive | XtRBoolean |
XtNwidth | XtCWidth | XtRDimension |
XtNx | XtCPosition | XtRPosition |
XtNy | XtCPosition | XtRPosition |
All fields in
RectObjPart
have the same default values as the corresponding fields in
CorePart
.
The WidgetClass arguments to the following procedures may be
rectObjClass
or any subclass:
The Widget arguments to the following procedures may be of class RectObj or any subclass:
The return value of the following procedures will be of class RectObj or a subclass:
RectObj can be subclassed to provide widgetlike objects (sometimes called gadgets) that do not use windows and do not have those features that are seldom used in simple widgets. This can save memory resources both in the server and in applications but requires additional support code in the parent. In the following discussion, rectobj refers only to objects whose class is RectObj or a subclass of RectObj, but not Core or a subclass of Core.
Composite
widget classes that wish to accept rectobj children must set
the accepts_objects field in the
CompositeClassExtension
extension structure to
True
.
XtCreateWidget
or
XtCreateManagedWidget
will otherwise generate an error if called to create a nonwidget child.
If the composite widget supports only children of class
RectObj
or a subclass (i.e., not of the general Object class), it
must declare an insert_child procedure and check the subclass of each
new child in that procedure. None of the classes defined by the
Intrinsics accept rectobj children.
If gadgets are defined in an object set, the parent is responsible for much more than the parent of a widget. The parent must request and handle input events that occur for the gadget and is responsible for making sure that when it receives an exposure event the gadget children get drawn correctly. Rectobj children may have expose procedures specified in their class records, but the parent is free to ignore them, instead drawing the contents of the child itself. This can potentially save graphics context switching. The precise contents of the exposure event and region arguments to the RectObj expose procedure are not specified by the Intrinsics; a particular rectangle object is free to define the coordinate system origin (self-relative or parent-relative) and whether or not the rectangle or region is assumed to have been intersected with the visible region of the object.
In general, it is expected that a composite widget that accepts nonwidget children will document those children it is able to handle, since a gadget cannot be viewed as a completely self-contained entity, as can a widget. Since a particular composite widget class is usually designed to handle nonwidget children of only a limited set of classes, it should check the classes of newly added children in its insert_child procedure to make sure that it can deal with them.
The Intrinsics will clear areas of a parent window obscured by rectobj children, causing exposure events, under the following circumstances:
A rectobj child is managed or unmanaged.
In a call to
XtSetValues
on a rectobj child, one or more of the set_values procedures returnsTrue
.In a call to
XtConfigureWidget
on a rectobj child, areas will be cleared corresponding to both the old and the new child geometries, including the border, if the geometry changes.In a call to
XtMoveWidget
on a rectobj child, areas will be cleared corresponding to both the old and the new child geometries, including the border, if the geometry changes.In a call to
XtResizeWidget
on a rectobj child, a single rectangle will be cleared corresponding to the larger of the old and the new child geometries if they are different.In a call to
XtMakeGeometryRequest
(orXtMakeResizeRequest
) on a rectobj child withXtQueryOnly
not set, if the manager returnsXtGeometryYes
, two rectangles will be cleared corresponding to both the old and the new child geometries.
Stacking order is not supported for rectobj children. Composite widgets with rectobj children are free to define any semantics desired if the child geometries overlap, including making this an error.
When a rectobj is playing the role of a widget, developers must be reminded to avoid making assumptions about the object passed in the Widget argument to a callback procedure.
The Intrinsics define an unnamed class between RectObj and Core for possible future use by the X Consortium. The only assumptions that may be made about the unnamed class are
The core_class.superclass field of
coreWidgetClassRec
contains a pointer to the unnamed class record.A pointer to the unnamed class record when dereferenced as an
ObjectClass
will contain a pointer torectObjClassRec
in its object_class.superclass field.
Except for the above, the contents of the class record for this class and the result of an attempt to subclass or to create a widget of this unnamed class are undefined.
The WidgetClass arguments to the following procedures must be of class Shell or a subclass:
The Widget arguments to the following procedures must be of class Core or any subclass:
XtAddEventHandler
,XtAddRawEventHandler
,XtRemoveEventHandler
,XtRemoveRawEventHandler
,XtInsertEventHandler
,XtInsertRawEventHandler
XtInsertEventTypeHandler
,XtRemoveEventTypeHandler
,XtAddGrab
,XtRemoveGrab
,XtGrabKey
,XtGrabKeyboard
,XtUngrabKey
,XtUngrabKeyboard
,XtGrabButton
,XtGrabPointer
,XtUngrabButton
,XtUngrabPointer
XtCreateWindow
,XtDisplay
,*XtScreen
,XtWindow
XtGetSelectionValue
,XtGetSelectionValues
,XtOwnSelection
,XtDisownSelection
,XtOwnSelectionIncremental
,XtGetSelectionValueIncremental
,XtGetSelectionValuesIncremental
,XtGetSelectionRequest
XtInstallAccelerators
,XtInstallAllAccelerators
(both destination and source)XtAugmentTranslations
,XtOverrideTranslations
,XtUninstallTranslations
,XtCallActionProc
XtCallAcceptFocus
,XtSetKeyboardFocus
(subtree)
The Widget arguments to the following procedures must be of class Composite or any subclass:
The Widget arguments to the following procedures must be of a subclass of Shell:
The return value of the following procedure will be of class Core or a subclass:
The return value of the following procedures will be of a subclass of Shell: