blob: 530f2f7f9bf5f719cc2a75f40d23ed2482797539 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
.LP
.bp
.if e .bp \" make sure we break on an odd page.
\&
.sp 1
.ce 3
\s+1\fBChapter 6\fP\s-1
\s+1\fBComposite and Constraint Widgets\fP\s-1
.sp 2
.nr H1 6
.nr H2 0
.nr H3 0
.nr H4 0
.nr H5 0
.na
.LP
.XS
Chapter 6 - Composite and Constraint Widgets
.XE
.LP
These widgets may contain arbitrary widget children. They implement a
policy for the size and location of their children.
.IP \fBBox\fP 1i
.IN "Box widget" ""
This widget will pack its children as tightly as possible in
non-overlapping rows.
.IP \fBDialog\fP 1i
.IN "Dialog widget" ""
An implementation of a commonly used interaction semantic to prompt for
auxiliary input from the user, such as a filename.
.IP \fBForm\fP 1i
.IN "Form widget" ""
A more sophisticated layout widget that allows the children to specify
their positions relative to the other children, or to the edges of the Form.
.IP \fBPaned\fP 1i
.IN "Paned widget" ""
Allows children to be tiled vertically or horizontally. Controls are
also provided to allow the user to dynamically resize the individual panes.
.IP \fBPorthole\fP 1i
.IN "Porthole widget" ""
Allows viewing of a managed child which is as large as, or larger than its
parent, typically under control of a Panner widget.
.IP \fBTree\fP 1i
.IN "Tree widget" ""
Provides geometry management of widgets arranged in a directed, acyclic graph.
.IP \fBViewport\fP 1i
.IN "Viewport widget" ""
Consists of a frame, one or two scrollbars, and an inner window. The
inner window can contain all the data that is to be displayed. This inner
window will be clipped by the frame with the scrollbars controlling
which section of the inner window is currently visible.
.LP
.NH 3
A Brief Note on Geometry Management
.IN "geometry management" ""
.LP
The geometry management semantics provided by the X Toolkit give full
control of the size and position of a widget to the parent of that
widget. While the children are allowed to request a certain size or
location, it is the parent who makes the final decision. Many of the
composite widgets here will deny any geometry request from their
children by default. If a child widget is not getting the expected size
or location, it is most likely the parent disallowing a request, or
implementing semantics slightly different than those expected by the
application programmer.
.LP
If the application wishes to change the size or location of
any widget it should make a call to \fBXtSetValues\fP. This will
.IN "XtSetValues" ""
allow the widget to ask its parent for the new size or location.
As noted above the parent is allowed to refuse this request,
and the child must live with the result. If the
application is unable to achieve the desired semantics, then perhaps it
should use a different composite widget. Under no circumstances
should an application programmer resort to \fBXtMoveWidget\fP or
.IN "XtMoveWidget" ""
\fBXtResizeWidget\fP; these functions are exclusively for the use of
.IN "XtResizeWidget" ""
Composite widget implementors.
.LP
For more information on geometry management consult the \fI\*(xT\fP.
|
