1tixForm(n) Tix Built-In Commands tixForm(n)
2
6 tixForm - Geometry manager based on attachment rules
7
9 tixForm option arg ?arg ...?
10
12 The tixForm command is used to communicate with the tixForm Geometry
13 Manager, a geometry manager that arranges the geometry of the children
14 in a parent window according to attachment rules. The tixForm geometry
15 manager is very flexible and powerful; it can be used to emulate all
16 the existing features of the Tk packer and placer geometry managers
17 (see pack(n), place(n)). The tixForm command can have any of several
18 forms, depending on the option argument:
19 tixForm slave ?options?
21 If the first argument to tixForm is a window name (any value
22 starting with ``.''), then the command is processed in the same
23 way as tixForm configure.
24 tixForm check master
26 This command checks whether there is circular dependency in the
27 attachments of the master's slaves (see the section CIRCULAR
28 DEPENDENCY below). It returns the Boolean value TRUE if it dis‐
29 cover circular dependency and FALSE otherwise.
30 tixForm configure slave ?-option value ...?
32 Sets or adjusts the attachment values of the slave window
33 according to the -option value argument pairs.
34 -b attachment
36 Abbreviation for the -bottom option.
37 -bottom attachment
39 Specifies an attachment for the bottom edge of the slave
40 window. The attachment must specied according to the sec‐
41 tion SPECIFYING ATTACHMENTS below.
42 -bottomspring weight
44 Specifies the weight of the spring at the bottom edge of
45 the slave window. See the section USING SPRINGS below.
46 -bp value
48 Abbreviation for the -padbottom option.
49 -bs weight
51 Abbreviation for the -bottomspring option.
52 -fill master
54 Specifies the fillings when springs are used for this
55 widget. The value must be x, y, both or none.
56 -in master
58 Places the slave window into the specified master window.
59 If the slave was originally in another master window, all
60 attachment values with respect to the original master
61 window are discarded. Even if the attachment values are
62 the same as in the original master window, they need to
63 be specified again. The -in flag, when needed, must
64 appear as the first flag after the name of the slave.
65 Otherwise an error is generated.
66 -l attachment
68 Abbreviation for the -left option.
69 -left attachment
71 Specifies an attachment for the left edge of the slave
72 window. The attachment must specied according to the sec‐
73 tion SPECIFYING ATTACHMENTS below.
74 -leftspring weight
76 Specifies the weight of the spring at the left edge of
77 the slave window. See the section USING SPRINGS below.
78 -lp value
80 Abbreviation for the -padleft option.
81 -ls weight
83 Abbreviation for the -leftspring option.
84 -padbottom value
86 Specifies the amount of external padding to leave on the
87 bottom side of the slave. The value may have any of the
88 forms acceptable to Tk_GetPixels(3).
89 -padleft value
91 Specifies the amount of external padding to leave on the
92 left side of the slave.
93 -padright value
95 Specifies the amount of external padding to leave on the
96 right side of the slave.
97 -padtop value
99 Specifies the amount of external padding to leave on the
100 top side of the slave.
101 -padx value
103 Specifies the amount of external padding to leave on both
104 the left and the right sides of the slave.
105 -pady value
107 Specifies the amount of external padding to leave on both
108 the top and the bottom sides of the slave.
109 -r attachment
111 Abbreviation for the -right option.
112 -right attachment
114 Specifies an attachment for the right edge of the slave
115 window. The attachment must specied according to the sec‐
116 tion SPECIFYING ATTACHMENTS below.
117 -rightspring weight
119 Specifies the weight of the spring at the right edge of
120 the slave window. See the section USING SPRINGS below.
121 -rp value
123 Abbreviation for the -padright option.
124 -rs weight
126 Abbreviation for the -rightspring option.
127 -t attachment
129 Abbreviation for the -top option.
130 -top attachment
132 Specifies an attachment for the top edge of the slave
133 window. The attachment must specied according to the sec‐
134 tion SPECIFYING ATTACHMENTS below.
135 -topspring weight
137 Specifies the weight of the spring at the top edge of the
138 slave window. See the section USING SPRINGS below.
139 -tp value
141 Abbreviation for the -padtop option.
142 -ts weight
144 Abbreviation for the -topspring option.
145 tixForm forget slave ?slave ...?
147 Removes each of the slaves from its master and unmaps their win‐
148 dows. The slaves will no longer be managed by tixForm. All
149 attachment values with respect to their master windows are dis‐
150 carded. If another slave is attached to this slave, then the
151 attachment of the other slave will be changed to grid attachment
152 based on its geometry.
153 tixForm grid master ?x_size y_size?
155 When x_size and y_size are given, this command returns the num‐
156 ber of grids of the master window in a pair of integers of the
157 form {x_size y_size}. When both x_size and y_size are given,
158 this command changes the number of horizontal and vertical grids
159 on the master window.
160 tixForm info slave ?option?
162 Queries the attachment options of a slave window. option can be
163 any of the options accepted by the tixForm configure command. If
164 option is given, only the value of that option is returned.
165 Otherwise, this command returns a list whose elements are the
166 current configuration state of the slave given in the same
167 option-value form that might be specified to tixForm configure.
168 The first two elements in this list list are "-in master" where
169 master is the slave's master window.
170 tixForm slaves master
172 Returns a list of all of the slaves for the master window. The
173 order of the slaves in the list is the same as their order in
174 the packing order. If master has no slaves then an empty string
175 is returned.
176
178 One can specify an attachment for each side of a slave window managed
179 by tixForm. An attachment is specified in the the form "-side
180 {anchor_point offset}". -side can be one of -top, -bottom, -left or
181 -right.
182 Offset is given in screen units (i.e. any of the forms acceptable to
184 Tk_GetPixels). A positive offset indicates shifting to a position to
185 the right or bottom of an anchor point. A negative offset indicates
186 shifting to a position to the left or top of an anchor point.
187 Anchor_point can be given in one of the following forms:
189 Grid Attachment
191 The master window is divided into a number of horizontal
192 and vertical grids. By default the master window is
193 divided into 100x100 grids; the number of grids can be
194 adjusted by the tixForm grid command. A grid attachment
195 anchor point is given by a % sign followed by an integer
196 value. For example, %0 spceifies the first grid line (the
197 top or left edge of the master window). %100 spceifies
198 the last grid line (the bottom or right edge of the mas‐
199 ter window).
200 Opposite Side Attachment
202 Opposite attachment specifies an anchor point located on
203 the opposite side of another slave widget, which must be
204 managed by tixForm in the same master window. An opposite
205 attachment anchor point is given by the name of another
206 widget. For example, "tixForm .b -top {.a 0}" attaches
207 the top side of the widget .b to the bottom of the widget
208 .a.
209 Parallel Side Attachment
211 Opposite attachment specifies an anchor point located on
212 the same side of another slave widget, which must be man‐
213 aged by tixForm in the same master window. An parallel
214 attachment anchor point is given by the sign & follwed by
215 the name of another widget. For example, "tixForm .b
216 -top {&.a 0}" attaches the top side of the widget .b to
217 the top of the widget .a, making the top sides of these
218 two widgets at the same vertical position in their parent
219 window.
220 No Attachment
222 Specifies a side of the slave to be attached to nothing,
223 indicated by the keyword none. When the none anchor point
224 is given, the offser must be zero.
225 When a side of a slave is attached to {none 0}, the posi‐
227 tion of this side is calculated by the position of the
228 other side and the natural size of the slave. For exam‐
229 ple, if a the left side of a widget is attached to {%0
230 100}, its right side attached to {none 0}, and the natu‐
231 ral size of the widget is 50 pixels, the right side of
232 the widget will be positioned at pixel {%0 149}.
233 When both -top and -bottom are attached to none, then by
235 default -top will be attached to {%0 0}. When both -left
236 and -right are attached to none, then by default -left
237 will be attached to {%0 0}.
238 Shifting effects can be achieved by specifying a non-zero offset with
240 an anchor point. In the following example, the top side of widget .b is
241 attached to the bottom of .a; hence .b always appears below .a. Also,
242 the left edge of .b is attached to the left side of .a with a 10 pixel
243 offest. Therefore, the left edge of .b is always shifted 10 pixels to
244 the right of .a's left edge:
245 tixForm .b -left {.a 10} -top {.a 0}
247 ABBREVIATIONS: Certain abbreviations can be made on the attachment
249 specifications: First an offset of zero can be omitted. Thus, the fol‐
250 lowing two lines are equivalent:
251 tixForm .b -top {.a 0} -right {%100 0} tixForm .b -top {.a} -right
253 {%100}
254 Also, because of the way TCL handles lists, when you omit the offset,
256 you can also leave out the braces. So you can further simplify the
257 above to:
258 tixForm .b -top .a -right %100
260 In the second case, when the anchor point is omitted, the offset must
262 be given. A default anchor point is chosen according to the value of
263 the offset. If the anchor point is 0 or positive, the default anchor
264 point %0 is used; thus, "tixForm .b -top 15" attaches the top edge of
265 .b to a position 15 pixels below the top edge of the master window. If
266 the anchor point is "-0" or negative, the default anchor point %100 is
267 used; thus, "tixForm .a -right -2" attaches the right edge of .a to a
268 position 2 pixels to the left of the master window's right edge. An
269 further example below shows a command with its equivalent abbreviation.
270 tixForm .b -top {%0 10} -bottom {%100 0} tixForm .b -top 10 -bot‐
271 tom -0
272
274 To be written.
275
277 TixForm starts with any slave in the list of slaves of the master win‐
278 dow. Then it tries to determine the position of each side of the slave.
279 If the attachment of a side of the slave is grid attachment, the posi‐
281 tion of the side is readily determined.
282 If the attachment of this side is none, then tixForm tries to determine
284 the position of the opposite side first, and then use the position of
285 the opposite side and the natural size of the slave to determine the
286 position of this side.
287 If the attachment is opposite or parallel widget attachments, then tix‐
289 Form tries to determine the positions of the other widget first, and
290 then use the positions of the other widget and the natural size of the
291 slave determine the position of this side. This recursive algorithmis
292 carried on until the positions of all slaves are determined.
293
295 The algorithm of tixForm will fail if a circular dependency exists in
296 the attachments of the slaves. For example:
297 tixForm .c -left .b tixForm .b -right .c
299 In this example, the position of the left side of .b depends on the
301 right side of .c, which in turn depends on the left side of .b.
302 When a circular dependency is discovered during the execution of the
304 tixForm algorithm, tixForm will generate a background error and the
305 geometry of the slaves are undefined (and will be arbitrary). Notice
306 that tixForm only executes the algorithm when the specification of the
307 slaves' attachments is complete. Therefore, it allows intermediate
308 states of circular dependency during the specification of the slaves'
309 attachments. Also, unlike the Motif Form manager widget, tixForm
310 defines circular dependency as "dependency in the same dimension".
311 Therefore, the following code fragment will does not have circular
312 dependency because the two widgets do not depend on each other in the
313 same dimension (.b depends .c in the horizontal dimension and .c
314 depends on .b in the vertical dimension):
315 tixForm .b -left .c tixForm .c -top .b
317
319 Springs have not been fully implemented yet.
320
322 Tix(n), Form, Geometry Management
323Tix 4.0 tixForm(n)