TIP #186: EXPOSE THE TYPE AND MODIFIED-STATE OF WIDGET OPTIONS ================================================================ Version: $Revision: 1.4 $ Author: Peter MacDonald Peter MacDonald State: Draft Type: Project Tcl-Version: 8.7 Vote: Pending Created: Friday, 16 April 2004 URL: https://tip.tcl-lang.org186.html Post-History: ------------------------------------------------------------------------- ABSTRACT ========== 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. RATIONALE =========== 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. SPECIFICATION =============== 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. NOTES ======= 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*) CHANGES ========= Threre are a couple of small changes to /tkConfig.c/ and /tkOldConfig.c/, plus a #define of *TK_OPTION_VALUE_SET* in /tk.h/ OVERHEAD/IMPACT ================= Scripts currently exploiting introspection and depending upon a list length of 5 may break. REFERENCE IMPLEMENTATION ========================== There is a simple implementation of the above available as a patch against Tk 8.4.2[]. It does not implement a enumerated flag for *optModified*, and the type string lookup is rather crude. COPYRIGHT =========== This document has been placed in the public domain. ------------------------------------------------------------------------- TIP AutoGenerator - written by Donal K. Fellows