1Tk_ConfigureWidget(3) Tk Library Procedures Tk_ConfigureWidget(3)
2______________________________________________________________________________
6
8 Tk_ConfigureWidget, Tk_ConfigureInfo, Tk_ConfigureValue, Tk_FreeOptions
9 - process configuration options for widgets
10
12 #include <tk.h>
13 int
15 Tk_ConfigureWidget(interp, tkwin, specs, argc, argv, widgRec, flags)
16 int
18 Tk_ConfigureInfo(interp, tkwin, specs, widgRec, argvName, flags)
19 int
21 Tk_ConfigureValue(interp, tkwin, specs, widgRec, argvName, flags)
22 Tk_FreeOptions(specs, widgRec, display, flags)
24
26 Tcl_Interp *interp (in) Interpreter to use for returning
27 error messages.
28 Tk_Window tkwin (in) Window used to represent widget
30 (needed to set up X resources).
31 Tk_ConfigSpec *specs (in) Pointer to table specifying legal
33 configuration options for this
34 widget.
35 int argc (in) Number of arguments in argv.
37 CONST char **argv (in) Command-line options for configur‐
39 ing widget.
40 char *widgRec (in/out) Points to widget record structure.
42 Fields in this structure get modi‐
43 fied by Tk_ConfigureWidget to hold
44 configuration information.
45 int flags (in) If non-zero, then it specifies an
47 OR-ed combination of flags that
48 control the processing of configu‐
49 ration information. TK_CON‐
50 FIG_ARGV_ONLY causes the option
51 database and defaults to be
52 ignored, and flag bits TK_CON‐
53 FIG_USER_BIT and higher are used
54 to selectively disable entries in
55 specs.
56 type name type (in) The name of the type of a widget
58 record.
59 field name field (in) The name of a field in records of
61 type type.
62 CONST char *argvName (in) The name used on Tcl command lines
64 to refer to a particular option
65 (e.g. when creating a widget or
66 invoking the configure widget com‐
67 mand). If non-NULL, then informa‐
68 tion is returned only for this
69 option. If NULL, then information
70 is returned for all available
71 options.
72 Display *display (in) Display containing widget whose
74 record is being freed; needed in
75 order to free up resources.
76_________________________________________________________________
77
79 Note: Tk_ConfigureWidget should be replaced with the new Tcl_Obj based │
80 API Tk_SetOptions. The old interface is retained for backward compati‐ │
81 bility.
82 Tk_ConfigureWidget is called to configure various aspects of a widget,
84 such as colors, fonts, border width, etc. It is intended as a conve‐
85 nience procedure to reduce the amount of code that must be written in
86 individual widget managers to handle configuration information. It is
87 typically invoked when widgets are created, and again when the config‐
88 ure command is invoked for a widget. Although intended primarily for
89 widgets, Tk_ConfigureWidget can be used in other situations where argc-
90 argv information is to be used to fill in a record structure, such as
91 configuring graphical elements for a canvas widget or entries of a
92 menu.
93 Tk_ConfigureWidget processes a table specifying the configuration
95 options that are supported (specs) and a collection of command-line
96 arguments (argc and argv) to fill in fields of a record (widgRec). It
97 uses the option database and defaults specified in specs to fill in
98 fields of widgRec that are not specified in argv. Tk_ConfigureWidget
99 normally returns the value TCL_OK; in this case it does not modify
100 interp. If an error occurs then TCL_ERROR is returned and Tk_Config‐
101 ureWidget will leave an error message in interp->result in the standard
102 Tcl fashion. In the event of an error return, some of the fields of
103 widgRec could already have been set, if configuration information for
104 them was successfully processed before the error occurred. The other
105 fields will be set to reasonable initial values so that Tk_FreeOptions
106 can be called for cleanup.
107 The specs array specifies the kinds of configuration options expected
109 by the widget. Each of its entries specifies one configuration option
110 and has the following structure:
111 typedef struct {
112 int type;
113 char *argvName;
114 char *dbName;
115 char *dbClass;
116 char *defValue;
117 int offset;
118 int specFlags;
119 Tk_CustomOption *customPtr;
120 } Tk_ConfigSpec;
121 The type field indicates what type of configuration option this is
122 (e.g. TK_CONFIG_COLOR for a color value, or TK_CONFIG_INT for an inte‐
123 ger value). The type field indicates how to use the value of the
124 option (more on this below). The argvName field is a string such as
125 ``-font'' or ``-bg'', which is compared with the values in argv (if
126 argvName is NULL it means this is a grouped entry; see GROUPED ENTRIES
127 below). The dbName and dbClass fields are used to look up a value for
128 this option in the option database. The defValue field specifies a
129 default value for this configuration option if no value is specified in
130 either argv or the option database. Offset indicates where in widgRec
131 to store information about this option, and specFlags contains addi‐
132 tional information to control the processing of this configuration
133 option (see FLAGS below). The last field, customPtr, is only used if
134 type is TK_CONFIG_CUSTOM; see CUSTOM OPTION TYPES below.
135 Tk_ConfigureWidget first processes argv to see which (if any) configu‐
137 ration options are specified there. Argv must contain an even number
138 of fields; the first of each pair of fields must match the argvName of
139 some entry in specs (unique abbreviations are acceptable), and the sec‐
140 ond field of the pair contains the value for that configuration option.
141 If there are entries in spec for which there were no matching entries
142 in argv, Tk_ConfigureWidget uses the dbName and dbClass fields of the
143 specs entry to probe the option database; if a value is found, then it
144 is used as the value for the option. Finally, if no entry is found in
145 the option database, the defValue field of the specs entry is used as
146 the value for the configuration option. If the defValue is NULL, or if
147 the TK_CONFIG_DONT_SET_DEFAULT bit is set in flags, then there is no
148 default value and this specs entry will be ignored if no value is spec‐
149 ified in argv or the option database.
150 Once a string value has been determined for a configuration option,
152 Tk_ConfigureWidget translates the string value into a more useful form,
153 such as a color if type is TK_CONFIG_COLOR or an integer if type is
154 TK_CONFIG_INT. This value is then stored in the record pointed to by
155 widgRec. This record is assumed to contain information relevant to the
156 manager of the widget; its exact type is unknown to Tk_ConfigureWid‐
157 get. The offset field of each specs entry indicates where in widgRec
158 to store the information about this configuration option. You should
159 use the Tk_Offset macro to generate offset values (see below for a
160 description of Tk_Offset). The location indicated by widgRec and off‐
161 set will be referred to as the ``target'' in the descriptions below.
162 The type field of each entry in specs determines what to do with the
164 string value of that configuration option. The legal values for type,
165 and the corresponding actions, are:
166 TK_CONFIG_ACTIVE_CURSOR
168 The value must be an ASCII string identifying a cursor in a form
169 suitable for passing to Tk_GetCursor. The value is converted to
170 a Tk_Cursor by calling Tk_GetCursor and the result is stored in
171 the target. In addition, the resulting cursor is made the
172 active cursor for tkwin by calling XDefineCursor. If TK_CON‐
173 FIG_NULL_OK is specified in specFlags then the value may be an
174 empty string, in which case the target and tkwin's active cursor
175 will be set to None. If the previous value of the target wasn't
176 None, then it is freed by passing it to Tk_FreeCursor.
177 TK_CONFIG_ANCHOR
179 The value must be an ASCII string identifying an anchor point in
180 one of the ways accepted by Tk_GetAnchor. The string is con‐
181 verted to a Tk_Anchor by calling Tk_GetAnchor and the result is
182 stored in the target.
183 TK_CONFIG_BITMAP
185 The value must be an ASCII string identifying a bitmap in a form
186 suitable for passing to Tk_GetBitmap. The value is converted to
187 a Pixmap by calling Tk_GetBitmap and the result is stored in the
188 target. If TK_CONFIG_NULL_OK is specified in specFlags then the
189 value may be an empty string, in which case the target is set to
190 None. If the previous value of the target wasn't None, then it
191 is freed by passing it to Tk_FreeBitmap.
192 TK_CONFIG_BOOLEAN
194 The value must be an ASCII string specifying a boolean value.
195 Any of the values ``true'', ``yes'', ``on'', or ``1'', or an
196 abbreviation of one of these values, means true; any of the val‐
197 ues ``false'', ``no'', ``off'', or ``0'', or an abbreviation of
198 one of these values, means false. The target is expected to be
199 an integer; for true values it will be set to 1 and for false
200 values it will be set to 0.
201 TK_CONFIG_BORDER
203 The value must be an ASCII string identifying a border color in
204 a form suitable for passing to Tk_Get3DBorder. The value is
205 converted to a (Tk_3DBorder *) by calling Tk_Get3DBorder and the
206 result is stored in the target. If TK_CONFIG_NULL_OK is speci‐
207 fied in specFlags then the value may be an empty string, in
208 which case the target will be set to NULL. If the previous
209 value of the target wasn't NULL, then it is freed by passing it
210 to Tk_Free3DBorder.
211 TK_CONFIG_CAP_STYLE
213 The value must be an ASCII string identifying a cap style in one
214 of the ways accepted by Tk_GetCapStyle. The string is converted
215 to an integer value corresponding to the cap style by calling
216 Tk_GetCapStyle and the result is stored in the target.
217 TK_CONFIG_COLOR
219 The value must be an ASCII string identifying a color in a form
220 suitable for passing to Tk_GetColor. The value is converted to
221 an (XColor *) by calling Tk_GetColor and the result is stored in
222 the target. If TK_CONFIG_NULL_OK is specified in specFlags then
223 the value may be an empty string, in which case the target will
224 be set to None. If the previous value of the target wasn't
225 NULL, then it is freed by passing it to Tk_FreeColor.
226 TK_CONFIG_CURSOR
228 This option is identical to TK_CONFIG_ACTIVE_CURSOR except that
229 the new cursor is not made the active one for tkwin.
230 TK_CONFIG_CUSTOM
232 This option allows applications to define new option types. The
233 customPtr field of the entry points to a structure defining the
234 new option type. See the section CUSTOM OPTION TYPES below for
235 details.
236 TK_CONFIG_DOUBLE
238 The value must be an ASCII floating-point number in the format
239 accepted by strtol. The string is converted to a double value,
240 and the value is stored in the target.
241 TK_CONFIG_END
243 Marks the end of the table. The last entry in specs must have
244 this type; all of its other fields are ignored and it will
245 never match any arguments.
246 TK_CONFIG_FONT
248 The value must be an ASCII string identifying a font in a form
249 suitable for passing to Tk_GetFont. The value is converted to a
250 Tk_Font by calling Tk_GetFont and the result is stored in the
251 target. If TK_CONFIG_NULL_OK is specified in specFlags then the
252 value may be an empty string, in which case the target will be
253 set to NULL. If the previous value of the target wasn't NULL,
254 then it is freed by passing it to Tk_FreeFont.
255 TK_CONFIG_INT
257 The value must be an ASCII integer string in the format accepted
258 by strtol (e.g. ``0'' and ``0x'' prefixes may be used to specify
259 octal or hexadecimal numbers, respectively). The string is con‐
260 verted to an integer value and the integer is stored in the tar‐
261 get.
262 TK_CONFIG_JOIN_STYLE
264 The value must be an ASCII string identifying a join style in
265 one of the ways accepted by Tk_GetJoinStyle. The string is con‐
266 verted to an integer value corresponding to the join style by
267 calling Tk_GetJoinStyle and the result is stored in the target.
268 TK_CONFIG_JUSTIFY
270 The value must be an ASCII string identifying a justification
271 method in one of the ways accepted by Tk_GetJustify. The string
272 is converted to a Tk_Justify by calling Tk_GetJustify and the
273 result is stored in the target.
274 TK_CONFIG_MM
276 The value must specify a screen distance in one of the forms
277 acceptable to Tk_GetScreenMM. The string is converted to dou‐
278 ble-precision floating-point distance in millimeters and the
279 value is stored in the target.
280 TK_CONFIG_PIXELS
282 The value must specify screen units in one of the forms accept‐
283 able to Tk_GetPixels. The string is converted to an integer
284 distance in pixels and the value is stored in the target.
285 TK_CONFIG_RELIEF
287 The value must be an ASCII string identifying a relief in a form
288 suitable for passing to Tk_GetRelief. The value is converted to
289 an integer relief value by calling Tk_GetRelief and the result
290 is stored in the target.
291 TK_CONFIG_STRING
293 A copy of the value is made by allocating memory space with mal‐
294 loc and copying the value into the dynamically-allocated space.
295 A pointer to the new string is stored in the target. If TK_CON‐
296 FIG_NULL_OK is specified in specFlags then the value may be an
297 empty string, in which case the target will be set to NULL. If
298 the previous value of the target wasn't NULL, then it is freed
299 by passing it to free.
300 TK_CONFIG_SYNONYM
302 This type value identifies special entries in specs that are
303 synonyms for other entries. If an argv value matches the argv‐
304 Name of a TK_CONFIG_SYNONYM entry, the entry isn't used
305 directly. Instead, Tk_ConfigureWidget searches specs for another
306 entry whose argvName is the same as the dbName field in the
307 TK_CONFIG_SYNONYM entry; this new entry is used just as if its
308 argvName had matched the argv value. The synonym mechanism
309 allows multiple argv values to be used for a single configura‐
310 tion option, such as ``-background'' and ``-bg''.
311 TK_CONFIG_UID
313 The value is translated to a Tk_Uid (by passing it to
314 Tk_GetUid). The resulting value is stored in the target. If
315 TK_CONFIG_NULL_OK is specified in specFlags and the value is an
316 empty string then the target will be set to NULL.
317 TK_CONFIG_WINDOW
319 The value must be a window path name. It is translated to a
320 Tk_Window token and the token is stored in the target.
321
324 In some cases it is useful to generate multiple resources from a single
325 configuration value. For example, a color name might be used both to
326 generate the background color for a widget (using TK_CONFIG_COLOR) and
327 to generate a 3-D border to draw around the widget (using TK_CON‐
328 FIG_BORDER). In cases like this it is possible to specify that several
329 consecutive entries in specs are to be treated as a group. The first
330 entry is used to determine a value (using its argvName, dbName,
331 dbClass, and defValue fields). The value will be processed several
332 times (one for each entry in the group), generating multiple different
333 resources and modifying multiple targets within widgRec. Each of the
334 entries after the first must have a NULL value in its argvName field;
335 this indicates that the entry is to be grouped with the entry that pre‐
336 cedes it. Only the type and offset fields are used from these follow-
337 on entries.
338
341 The flags argument passed to Tk_ConfigureWidget is used in conjunction
342 with the specFlags fields in the entries of specs to provide additional
343 control over the processing of configuration options. These values are
344 used in three different ways as described below.
345 First, if the flags argument to Tk_ConfigureWidget has the TK_CON‐
347 FIG_ARGV_ONLY bit set (i.e., flags | TK_CONFIG_ARGV_ONLY != 0), then
348 the option database and defValue fields are not used. In this case, if
349 an entry in specs doesn't match a field in argv then nothing happens:
350 the corresponding target isn't modified. This feature is useful when
351 the goal is to modify certain configuration options while leaving oth‐
352 ers in their current state, such as when a configure widget command is
353 being processed.
354 Second, the specFlags field of an entry in specs may be used to control
356 the processing of that entry. Each specFlags field may consists of an
357 OR-ed combination of the following values:
358 TK_CONFIG_COLOR_ONLY
360 If this bit is set then the entry will only be considered if the
361 display for tkwin has more than one bit plane. If the display
362 is monochromatic then this specs entry will be ignored.
363 TK_CONFIG_MONO_ONLY
365 If this bit is set then the entry will only be considered if the
366 display for tkwin has exactly one bit plane. If the display is
367 not monochromatic then this specs entry will be ignored.
368 TK_CONFIG_NULL_OK
370 This bit is only relevant for some types of entries (see the
371 descriptions of the various entry types above). If this bit is
372 set, it indicates that an empty string value for the field is
373 acceptable and if it occurs then the target should be set to
374 NULL or None, depending on the type of the target. This flag is
375 typically used to allow a feature to be turned off entirely,
376 e.g. set a cursor value to None so that a window simply inherits
377 its parent's cursor. If this bit isn't set then empty strings
378 are processed as strings, which generally results in an error.
379 TK_CONFIG_DONT_SET_DEFAULT
381 If this bit is one, it means that the defValue field of the
382 entry should only be used for returning the default value in
383 Tk_ConfigureInfo. In calls to Tk_ConfigureWidget no default
384 will be supplied for entries with this flag set; it is assumed
385 that the caller has already supplied a default value in the tar‐
386 get location. This flag provides a performance optimization
387 where it is expensive to process the default string: the client
388 can compute the default once, save the value, and provide it
389 before calling Tk_ConfigureWidget.
390 TK_CONFIG_OPTION_SPECIFIED
392 This bit is set and cleared by Tk_ConfigureWidget. Whenever
393 Tk_ConfigureWidget returns, this bit will be set in all the
394 entries where a value was specified in argv. It will be zero in
395 all other entries. This bit provides a way for clients to
396 determine which values actually changed in a call to Tk_Config‐
397 ureWidget.
398 The TK_CONFIG_MONO_ONLY and TK_CONFIG_COLOR_ONLY flags are typically
400 used to specify different default values for monochrome and color dis‐
401 plays. This is done by creating two entries in specs that are identi‐
402 cal except for their defValue and specFlags fields. One entry should
403 have the value TK_CONFIG_MONO_ONLY in its specFlags and the default
404 value for monochrome displays in its defValue; the other entry entry
405 should have the value TK_CONFIG_COLOR_ONLY in its specFlags and the
406 appropriate defValue for color displays.
407 Third, it is possible to use flags and specFlags together to selec‐
409 tively disable some entries. This feature is not needed very often.
410 It is useful in cases where several similar kinds of widgets are imple‐
411 mented in one place. It allows a single specs table to be created with
412 all the configuration options for all the widget types. When process‐
413 ing a particular widget type, only entries relevant to that type will
414 be used. This effect is achieved by setting the high-order bits (those
415 in positions equal to or greater than TK_CONFIG_USER_BIT) in specFlags
416 values or in flags. In order for a particular entry in specs to be
417 used, its high-order bits must match exactly the high-order bits of the
418 flags value passed to Tk_ConfigureWidget. If a specs table is being
419 used for N different widget types, then N of the high-order bits will
420 be used. Each specs entry will have one of more of those bits set in
421 its specFlags field to indicate the widget types for which this entry
422 is valid. When calling Tk_ConfigureWidget, flags will have a single
423 one of these bits set to select the entries for the desired widget
424 type. For a working example of this feature, see the code in tkBut‐
425 ton.c.
426
429 The Tk_Offset macro is provided as a safe way of generating the offset
430 values for entries in Tk_ConfigSpec structures. It takes two argu‐
431 ments: the name of a type of record, and the name of a field in that
432 record. It returns the byte offset of the named field in records of
433 the given type.
434
437 The Tk_ConfigureInfo procedure may be used to obtain information about
438 one or all of the options for a given widget. Given a token for a win‐
439 dow (tkwin), a table describing the configuration options for a class
440 of widgets (specs), a pointer to a widget record containing the current
441 information for a widget (widgRec), and a NULL argvName argument,
442 Tk_ConfigureInfo generates a string describing all of the configuration
443 options for the window. The string is placed in interp->result. Under
444 normal circumstances it returns TCL_OK; if an error occurs then it
445 returns TCL_ERROR and interp->result contains an error message.
446 If argvName is NULL, then the value left in interp->result by Tk_Con‐
448 figureInfo consists of a list of one or more entries, each of which
449 describes one configuration option (i.e. one entry in specs). Each
450 entry in the list will contain either two or five values. If the cor‐
451 responding entry in specs has type TK_CONFIG_SYNONYM, then the list
452 will contain two values: the argvName for the entry and the dbName
453 (synonym name). Otherwise the list will contain five values: argv‐
454 Name, dbName, dbClass, defValue, and current value. The current value
455 is computed from the appropriate field of widgRec by calling procedures
456 like Tk_NameOfColor.
457 If the argvName argument to Tk_ConfigureInfo is non-NULL, then it indi‐
459 cates a single option, and information is returned only for that
460 option. The string placed in interp->result will be a list containing
461 two or five values as described above; this will be identical to the
462 corresponding sublist that would have been returned if argvName had
463 been NULL.
464 The flags argument to Tk_ConfigureInfo is used to restrict the specs
466 entries to consider, just as for Tk_ConfigureWidget.
467
470 Tk_ConfigureValue takes arguments similar to Tk_ConfigureInfo; instead
471 of returning a list of values, it just returns the current value of the
472 option given by argvName (argvName must not be NULL). The value is
473 returned in interp->result and TCL_OK is normally returned as the pro‐
474 cedure's result. If an error occurs in Tk_ConfigureValue (e.g., argv‐
475 Name is not a valid option name), TCL_ERROR is returned and an error
476 message is left in interp->result. This procedure is typically called
477 to implement cget widget commands.
478
481 The Tk_FreeOptions procedure may be invoked during widget cleanup to
482 release all of the resources associated with configuration options. It
483 scans through specs and for each entry corresponding to a resource that
484 must be explicitly freed (e.g. those with type TK_CONFIG_COLOR), it
485 frees the resource in the widget record. If the field in the widget
486 record doesn't refer to a resource (e.g. it contains a null pointer)
487 then no resource is freed for that entry. After freeing a resource,
488 Tk_FreeOptions sets the corresponding field of the widget record to
489 null.
490
493 Applications can extend the built-in configuration types with addi‐
494 tional configuration types by writing procedures to parse and print
495 options of the a type and creating a structure pointing to those proce‐
496 dures:
497 typedef struct Tk_CustomOption {
498 Tk_OptionParseProc *parseProc;
499 Tk_OptionPrintProc *printProc;
500 ClientData clientData;
501 } Tk_CustomOption;
502 typedef int Tk_OptionParseProc(
504 ClientData clientData,
505 Tcl_Interp *interp,
506 Tk_Window tkwin,
507 char *value,
508 char *widgRec,
509 int offset);
510 typedef char *Tk_OptionPrintProc(
512 ClientData clientData,
513 Tk_Window tkwin,
514 char *widgRec,
515 int offset,
516 Tcl_FreeProc **freeProcPtr);
517 The Tk_CustomOption structure contains three fields, which are pointers
518 to the two procedures and a clientData value to be passed to those pro‐
519 cedures when they are invoked. The clientData value typically points
520 to a structure containing information that is needed by the procedures
521 when they are parsing and printing options.
522 The parseProc procedure is invoked by Tk_ConfigureWidget to parse a
524 string and store the resulting value in the widget record. The client‐
525 Data argument is a copy of the clientData field in the Tk_CustomOption
526 structure. The interp argument points to a Tcl interpreter used for
527 error reporting. Tkwin is a copy of the tkwin argument to Tk_Config‐
528 ureWidget. The value argument is a string describing the value for the
529 option; it could have been specified explicitly in the call to Tk_Con‐
530 figureWidget or it could come from the option database or a default.
531 Value will never be a null pointer but it may point to an empty string.
532 RecordPtr is the same as the widgRec argument to Tk_ConfigureWidget;
533 it points to the start of the widget record to modify. The last argu‐
534 ment, offset, gives the offset in bytes from the start of the widget
535 record to the location where the option value is to be placed. The
536 procedure should translate the string to whatever form is appropriate
537 for the option and store the value in the widget record. It should
538 normally return TCL_OK, but if an error occurs in translating the
539 string to a value then it should return TCL_ERROR and store an error
540 message in interp->result.
541 The printProc procedure is called by Tk_ConfigureInfo to produce a
543 string value describing an existing option. Its clientData, tkwin,
544 widgRec, and offset arguments all have the same meaning as for
545 Tk_OptionParseProc procedures. The printProc procedure should examine
546 the option whose value is stored at offset in widgRec, produce a string
547 describing that option, and return a pointer to the string. If the
548 string is stored in dynamically-allocated memory, then the procedure
549 must set *freeProcPtr to the address of a procedure to call to free the
550 string's memory; Tk_ConfigureInfo will call this procedure when it is
551 finished with the string. If the result string is stored in static
552 memory then printProc need not do anything with the freeProcPtr argu‐
553 ment.
554 Once parseProc and printProc have been defined and a Tk_CustomOption
556 structure has been created for them, options of this new type may be
557 manipulated with Tk_ConfigSpec entries whose type fields are TK_CON‐
558 FIG_CUSTOM and whose customPtr fields point to the Tk_CustomOption
559 structure.
560
563 Although the explanation of Tk_ConfigureWidget is fairly complicated,
564 its actual use is pretty straightforward. The easiest way to get
565 started is to copy the code from an existing widget. The library
566 implementation of frames (tkFrame.c) has a simple configuration table,
567 and the library implementation of buttons (tkButton.c) has a much more
568 complex table that uses many of the fancy specFlags mechanisms.
569
572 Tk_SetOptions(3)
573
576 anchor, bitmap, boolean, border, cap style, color, configuration
577 options, cursor, custom, double, font, integer, join style, justify,
578 millimeters, pixels, relief, synonym, uid
579Tk 4.1 Tk_ConfigureWidget(3)