Page: | 1 | 2 | 3 | 4 | 5 | 6 |
---|
Composite widgets (widgets whose class is
a subclass of compositeWidgetClass) can have an arbitrary
number of children. Consequently, they are responsible for much
more than primitive widgets. Their responsibilities (either implemented
directly by the widget class or indirectly by Intrinsics functions)
include
Overall management is handled by the generic
procedures XtCreateWidget and XtDestroyWidget. XtCreateWidget
adds children to their parent by calling the parent's insert_child
procedure. XtDestroyWidget removes children from their
parent by calling the parent's delete_child procedure and ensures
that all children of a destroyed composite widget also get destroyed.
Only a subset of the total number of children
is actually managed by the geometry manager and hence possibly
visible. For example, a composite editor widget supporting multiple
editing buffers might allocate one child widget for each file
buffer, but it might only display a small number of the existing
buffers. Widgets that are in this displayable subset are called
managed widgets and enter into geometry manager calculations.
The other children are called unmanaged widgets and, by definition,
are not mapped by the Intrinsics.
Children are added to and removed from their parent's managed set by using XtManageChild, XtManageChildren, XtUnmanageChild, XtUnmanageChildren, and XtChangeManagedSet, which notify the parent to recalculate the physical layout of its children by calling the parent's change_managed procedure. The XtCreateManagedWidget convenience function calls XtCreateWidget and XtManageChild on the result.
Most managed children are mapped, but some
widgets can be in a state where they take Up physical space but
do not show anything. Managed widgets are not mapped automatically
if their map_when_managed field is False. The default
is True and is changed by using XtSetMappedWhenManaged
.
Each composite widget class declares a geometry
manager, which is responsible for figuring out where the managed
children should appear within the composite widget's window. Geometry
management techniques fall into four classes:
Home |
---|
To add a child to the parent's list of children,
the ,XtCreateWidget function calls the parent's class routine insert_child.
The insert_child procedure pointer in a composite widget is of
type XtWidgetProc.
w | Passes the newly created child. |
Most composite widgets inherit their superclass's
operation. The insert_child routine in CompositeWidgetClass
calls and inserts the child at the specified position in
the children list, expanding it if necessary.
Some composite widgets define their own insert_child
routine so that they can order their children in some convenient
way, create companion controller widgets for a new widget, or
limit the number or class of their child widgets. A composite
widget class that wishes to allow nonwidget children (see Chapter 12) must specify a CompositeClassExtension extension record
as described in section 1.4.2.1 and set the accepts_objects
field in this record to True. If the CompositeClassExtension
record is not specified or the accepts_objects field is
False, the composite widget can assume that all its children
are of a subclass of Core without an explicit subclass test in
the insert_child procedure.
If there is not enough room to insert a new
child in the children array (that is, num_children is
equal to num slots),the insert_child procedure must
first reallocate the array and update num_slots. The insert_child
procedure then places the child at the appropriate position in
the array and increments the num_children field.
Home |
---|
Instances of composite widgets sometimes need
to specify more about the order in which their children are kept.
For example, an application may want a set of command buttons
in some logical order grouped by function, and it may want buttons
that represent file names to be kept in alphabetical order without
constraining the order in which the buttons are created.
An application controls the presentation order
of a set of children by supplying an XtNinsertPosition resource.
The insert_position procedure pointer in a composite widget instance
is of type XtOrderProc.
w | Passes the newly created widget. |
Composite widgets that allow clients to order
their children (usually homogeneous boxes) can call their widget
instance's insert_position procedure from the class's insert_child
procedure to determine where a new child should go in its children
array. Thus, a client using a composite class can apply different
sorting criteria to widget instances of the class, passing in
a different insert_position procedure resource when it creates
each composite widget instance.
The return value of the insert_position procedure
indicates how many children should go before the widget. Returning
zero indicates that the widget should go before all other children,
and returning num_children indicates that it should go
after all other children. The default insert_position function
returns num_children and can be overridden by a specific
composite widget's resource list or by the argument list provided
when the composite widget is created.
Home |
---|
To remove the child from the parent's children
list, the XtDestroyWidget function eventually causes
a call to the Composite parent's class delete_child procedure.
The delete_child procedure pointer is of type XtWidgetProc.
w | Passes the child being deleted. |
Most widgets inherit the delete_child procedure
from their superclass. Composite widgets that create companion
widgets define their own delete_child procedure to remove these
companion widgets.
Home |
---|
The Intrinsics provide a set of generic routines
to permit the addition of widgets to or the removal of widgets
from a composite widget's managed set. These generic routines
eventually call the composite widget's change_managed procedure
if the procedure pointer is non-NULL. The change_managed procedure
pointer is of type XtWidgetProc. The widget argument specifies
the composite widget whose managed child set has been modified.
3.4.1. Managing Children
To add a list of widgets to the geometry-managed (and hence displayable) subset of their Composite parent, use XtManageChildren.
typedef Widget *WidgetList;
children | Specifies a list of child widgets. Each child must be of class RectObj or any subclass thereof. |
num_children | Specifies the number of children in the list. |
The XtManageChildren function performs
the following:
Managing children is independent of the ordering
of children and independent of creating and deleting children.
The layout routine of the parent should consider children whose
managed field is True and should ignore all other
children. Note that some composite widgets, especially fixed
boxes, call XtManageChild from their insert_child procedure.
If the parent widget is realized, its change_managed
procedure is called to notify it that its set of managed children
has changed. The parent can reposition and resize any of its children.
It moves each child as needed by calling XtMoveWidget,
which first updates the x and y fields and which then calls XMoveWindow.
If the composite widget wishes to change the
size or border width of any of its children, it calls XtResizeWidget,
which first updates the width, height, and border_ width
fields and then calls XConflgureWindow. Simultaneous
repositioning and resizing may be done with XtConfigureWidget;
see Section 6.6.
To add a single child to its parent widget's
set of managed children, use XtManageChild.
child | Specifies the child. Must be of class RectObj or any subclass thereof. |
The XtManageChild function constructs
aWidgetList of length 1 and calls XtManageChildren
.
To create and manage a child widget in
a single procedure, use XtCreateManagedWidget or XtVaCreateManagedWidget
.
name | Specifies the resource instance name for the created widget. |
widget_class | Specifies the widget class pointer for the created widget. Must be rectObjClass or any subclass thereof. |
parent | Specifies the parent widget. Must be of class Composite or any subclass thereof. |
args | Specifies the argument list to override any other resource specifications. |
num_args | Specifies the number of entries in the argument list. |
The XtCreateManagedWidget function is a convenience
routine that calls XtCreateWidget and XtManageChild.
name | Specifies the resource instance name for the created widget. |
widget_class | Specifies the widget class pointer for the created widget. Must be rectObjClass or any subclass thereof. |
parent | Specifies the parent widget. Must be of class Composite or any subclass thereof. |
... | Specifies the variable argument list to override any other resource specifications. |
XtVaCreateManagedWidget
is identical in function to XtCreateManagedWidget with
the args and num_args parameters replaced by a varargs
list, as described in Section 2.5.1.
3.4.2. Unmanaging Children
To remove a list of children from a parent widget's managed list,
use XtUnmanageChildren.
children | Specifies a list of child widgets. Each child must be of class RectObj or any subclass thereof. |
num_children | Specifies the number of children. |
The XtUnmanageChildren function performs
the following:
- | Marks the child as unmanaged. |
- | If the child is realized and the map_when_managed field is True, it is unmapped. |
XtUnmanageChildren
does not destroy the child widgets. Removing widgets from a parent's
managed set is often a temporary banishment, and some time later
the client may manage the children again. To destroy widgets entirely,
XtDestroyWidget should be called instead; see Section 2.9.
To remove a single child from its parent widget's
managed set, use XtUnmanageChild.
child | Specifies the child. Must be of class RectObj or any subclass thereof. |
The XtUnmanageChild function constructs
a widget list of length 1 and calls XtUnmanageChildren
.
These functions are low-level routines that
are used by generic composite widget building routines. In addition,
composite widgets can provide widget-specific, high-level convenience
procedures.
3.4.3. Bundling Changes to the Managed Set
A client may simultaneously unmanage and manage
children with a single call to the Intrinsics. In this same call
the client may provide a callback procedure that can modify the
geometries of one or more children. The composite widget class
defines whether this single client call results in separate invocations
of the change_managed method, one to unmanage and the other to
manage, or in just a single invocation.
unmanage_children | Specifies the list of widget children to initially remove from the managed set. |
num_unmanage_children | Specifies the number of entries in the unmanage_children list. |
do_change_proc | Specifies a procedure to invoke between unmanaging and managing the children, or NULL. |
client_data | Specifies client data to be passed to the do_change_proc. |
manage_children | Specifies the list of widget children to finally add to the managed set. |
nurn_manage_children | Specifies the number of entries in the manage_children list. |
The XtChangeManagedSet function performs
the following:
- | Calls XtUnmanageChildren (unmanage_children, num_unmanage_children). |
- | Calls the do_change_porch. |
- | Calls XtManageChildren (manage_children, num_manage_children). |
If no CompositeClassExtension record
is found in the parent's composite class part extension field
with record type NULLQUARK and version greater than 1 and if XtInheritChangeManaged
was specified in the parent's class record during class initialization,
the value of the allows_change_tmanaged_set field is inherited
from the superclass. The value inherited from compositeWidgetClass
for the allows_change_managed_set field is False.
It is not an error to include a child in both
the unmanage_children and the manage_children lists.
The effect of such a call is that the child remains managed following
the call but the do_change_proc is able to affect the child
while it is in an unmanaged state.
The do_change_proc is of type XtDoChangeProc.
The do_change_proc procedure is used
by the caller of XtChangeManagedSet to make changes to
one or more children at the point when the managed set contains
the fewest entries. These changes may involve geometry requests
and in this case the caller of XtChangeManagedSet may take
advantage of the fact that the Intrinsics internally grant geometry
requests made by unmanaged children without invoking the parent's
geometry manager. To achieve this advantage, if the do_change_proc
procedure changes the geometry of a child or of a descendant
of a child then that child should be included in the unmanage_children
and manage_children lists.
3.4.4. Determining If a Widget Is Managed
To determine the managed state of a given child widget, use XtIsManaged.
w | Specifies the widget. Must be of class Object or any subclass thereof. |
The XtIsManaged function returns True
if the specified widget is of class RectObj or any subclass thereof
and is managed, or False otherwise.
Home |
---|
A widget is normally mapped if it is managed.
However, this behavior can be overridden by setting the XmNmappedWhenManaged
resource for the widget when it is created or by setting the map_when_managed field to False.
To change the value of a given widget's map_
when_managed field, use XtSetMappedWhenManaged .
w | Specifies the widget. Must be of class Core or any subclass thereof. |
map_when_managed | Specifies a Boolean value that indicates the new value that is stored into the widget's map_when_managedfield. |
If the widget is realized and managed and
if map_when_managed is True,
XtSetMappedWhenManaged maps the window. If the widget is
realized and managed and if map_when_
managed is False,
it unmaps the window. XtSetMappedWhenManaged is a convenience
function that is equivalent to (but slightly faster than) calling
XtSetValues and setting the new value for the XtNmappedWhenManaged
resource then mapping the widget as appropriate. As an alternative
to using
XtSetMappedWhenManaged to control mapping, a client may
set mapped when managed to
False and use XtMapWidget and XtUnmapWidget
explicitly.
To map a widget explicitly, use XtMapWidget.
w | Specifies the widget. Must be of class Core or any subclass thereof. |
To unmap a widget explicitly, use XtUnmapWidget.
w | Specifies the widget. Must be of class Core or any subclass thereof. |
Home |
---|
The Constraint widget class is a subclass
of compositeWidgetClass. The name is derived from the fact
that constraint widgets may manage the geometry of their children
based on constraints associated with each child. These constraints
can be as simple as the maximum width and height the parent will
allow the child to occupy or can be as complicated as how other
children should change if this child is moved or resized. Constraint
widgets let a parent define constraints as resources that are
supplied for their children. For example, if the Constraint parent
defines the maximum sizes for its children, these new size resources
are retrieved for each child as if they were resources that were
defined by the child widget's class. Accordingly, constraint resources
may be included in the argument list or resource file just like
any other resource for the child.
Constraint widgets have all the responsibilities
of normal composite widgets and, in addition, must process and
act upon the constraint information associated with each of their
children.
To make it easy for widgets and the Intrinsics
to keep track of the constraints associated with a child, every
widget has a constraints field, which is the address of
a parent-specific structure that contains constraint information
about the child. If a child's parent does not belong to a subclass
of constraintWidgetClass, then the child's constraints
field is NULL.
Subclasses of Constraint can add constraint
data to the constraint record defined by their superclass. To
allow this, widget writers should define the constraint records
in their private .h file by using the same conventions as used
for widget records. For example, a widget class that needs to
maintain a maximum width and height for each child might define
its constraint record as follows:
typedef struct { Dimension max_width, max_height; } Max Constrain tPart; typedef struct { MaxConstraintPart max; } MaxConstraintRecord, *MaxConstraint;
typedef struct { Dimension min_width, min_height; } MinConstraintPart; typedef struct { MaxConstraintPart max; MinConstraintPart min; } MaxMinConstraintRecord, *MaxMinConstraint;
The XtCreateWidget function uses the
constraint size field in the parent's class record to allocate
a constraint record when a child is created. XtCreateWidget
also uses the constraint resources to fill in resource fields
in the constraint record associated with a child. It then calls
the constraint initialize procedure so that the parent can compute
constraint fields that are derived from constraint resources and
can possibly move or resize the child to conform to the given
constraints.
When the XtGetValues and XtSetValues
functions are executed on a child, they use the constraint resources
to get the values or set the values of constraints associated
with that child. XtSetValues then calls the constraint
set_values procedures so that the parent can recompute derived
constraint fields and move or resize the child as appropriate.
If a Constraint widget class or any of its superclasses have declared
a ConstraintClassExtension record in the ConstraintClassPart
extension fields with a record type of NULLQUARK and the
get_values_hook field in the extension record is non-NULL,
XtGetValues calls the get_values_hook procedure(s) to allow
the parent to return derived constraint fields.
The XtDestroyWidget function calls
the constraint destroy procedure to delicate any dynamic storage
associated with a constraint record. The constraint record itself
must not be deallocated by the constraint destroy procedure; XtDestroyWidget
does this automatically.
Home |
---|
Contents | Previous Chapter | Next Chapter |