| Page: | 1 | 2 | 3 | 4 | 5 |
|---|
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.
| Home |
|---|
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.
| Home |
|---|
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.
12.2.1. ObjectClassPart Structure
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.
The extension record defined for ObjectClassPart with a record_type equal to NULLQUARK is ObjectClassExtensionRec.
| XtPointer next_extension; | See Section 1.6.12 |
| XrmQuark record_type; | See Section 1.6.12 |
| long version; | See Section 1.6.12 |
| Cardinal record_size; | See Section 1.6.12 |
| XtAllocateProc allocate; | See Section 2.5.5. |
| XtDeallocateProc deallocate; | See Section 2.8.4. |
The predefined class record and pointer for ObjectClassRec
are
extern ObjectClassRec objectClassRec;
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 Section 1.6.12). 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.
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 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 |
12.2.4. ObjectPart Default Values
All fields in ObjectPart have the same default values as
the corresponding fields in CorePart.
12.2.5. Object Arguments To Intrinsics Routines
XtAddCallback, XtAddCallbacks, XtRemoveCallback,
XtRemoveCallbacks, XtRemoveAIICallbacks, XtCallCallbacks, XtHasCallbacks, XtCallCallbackList
XtClass, XtSuperclass, XtIsSubclass,
XtCheckSubclass, XtIsObject, XtIsRectObj,
XtIsWidget, XtIsComposite, XtIsConstraint,
XtIsShell, XtIsOverrideShell, XtIsWMShell, XtIsVendorShell, XtIsTransientShell,
XtIsToplevelShell, XtIsApplicationShell, XtIsSessionShell
XtIsManaged, XtIsSensitive
(both will return False 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)
XtWidgetToApplicationContext
XtDestroyWidget
XtParent, XtDisplayOfObject, XtScreenOfObject,
XtWindowOfObject
XtSetKeyboardFocus (descendant)
XtGetGC, XtReleaseGC
XtName
XtSetValues, XtGetValues, XtVaSetValues,
XtVaGetValues
XtGetSubresources, XtGetApplicationResources,
XtVaGetSubresources, XtVaGetApplicationResources XtConvert,
XtConvertAndStore
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.
| Home |
|---|
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.
12.3.1. RectObjClassPart Structure
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.
The RectObj class record consists of just the RectObjClassPart
The predefined class record and pointer for RectObjClassRecare
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.
RectObj objects have the RectObj fields immediately following the Object fields.
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 |
12.3.4. RectObjPart Default Values
All fields in RectObjPart have the same default values
as the corresponding fields in CorePart.
12.3.5. Widget Arguments To Intrinsics Routines
12.3.6. Use of Rectangle Objects
RectObj can be subclassed to provide widgetlike objects (sometimes
called gadgets) that do not use windows and do not have features
often unused 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:
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.
| Home |
|---|
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
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.
| Home |
|---|
XtAddEventHandler, XtAddRawEventHandler, XtRemoveEventHandler,
XtRemoveRawEventHandler, XtInsertEventHandler, XtInsertRawEventHandler
XtInsertEventTypeHandler, XtRemoveEventTypeHandler,
XtRegisterDrawable XtDispatchEventToWidget
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
XtRealizeWidget, XtUnrealizeWidget
XtCallAcceptFocus, XtSetKeyboardFocus (subtree)
| Home |
|---|
| Contents | Previous Chapter | Next Chapter |