This is not necessarily the current version of this TIP.This is not necessarily the current version of this TIP.
| TIP: | 186 |
| Title: | Expose the Type and Modified-State of Widget Options |
| Version: | $Revision: 1.4 $ |
| Authors: |
Peter MacDonald <pmacdona at pdqi dot com> Peter MacDonald <peter at pdqi dot com> |
| State: | Draft |
| Type: | Project |
| Tcl-Version: | 8.7 |
| Vote: | Pending |
| Created: | Friday, 16 April 2004 |
| Keywords: | Tk |
This TIP adds a 6th (and 7th element) to each option in the output of [path configure] for Tk widgets, indicating the type and modified status of each option respectively.
The configure subcommand of Tk widgets provides a powerful method for introspection of widget state information. Unfortunately, two important pieces of information are currently unavailable. Namely, the type Tk is expecting for an option and the whether a user has explicitly assigned a value.
The type field is valuable in automating interfaces for editing the contents of widgets.
The modified field is useful in changing styles (such as in tk_setPalette) where we update all widgets that are currently using default values.
The configure subcommand for Tk widgets, when invoked with no arguments, currently dumps out all options as a list with 5 elements per-option: optName, dbName, dbClass, defValue, optValue. This TIP proposes adding up to 2 additional values: optType and optModified.
A 6th element, optType, is a string representation of the type field of Tk_ConfigSpec and Tk_OptionSpec.
For widgets using the new Tk_OptionSpec, a 7th appended element indicates whether an option has been set by the user.
Perhaps optModified should be specified as an enumeration. For example:
1 = USER_MODIFIED
2 = OPTION_DATABASE
3 = SYSTEM_DEFAULT
4 = TABLE_DEFAULT
In addition, as much of the Tk core is still using Tk_ConfigSpec, would some form of compatibility interface make sense whereby a Tk_ConfigSpec could be used to dynamically produce a Tk_OptionSpec? (This last is out of the scope of this TIP.)
Probably also need a way to change options such that the USER_MODIFIED flag does not get set. (eg. tk_setPalette)
Threre are a couple of small changes to tkConfig.c and tkOldConfig.c, plus a #define of TK_OPTION_VALUE_SET in tk.h
Scripts currently exploiting introspection and depending upon a list length of 5 may break.
There is a simple implementation of the above available as a patch against Tk 8.4.2[1]. It does not implement a enumerated flag for optModified, and the type string lookup is rather crude.
This document has been placed in the public domain.
This is not necessarily the current version of this TIP.