May 03, 2001, 8:09 PM — Modern scripting languages have come a long way toward achieving portability in the last couple of years. Even portable tools, though, benefit from platform-specific instruction.
The Tk option database is portable in the sense that it's documented identically for Mac OS, Unix, Windows, and the other operating systems for which Tk is available. However, you're likely to make different use of its functions on different platforms. Mac OS, Unix, and Windows all customize application instances by assigning values to resources or properties. The Tk option database is a child of the particular scheme that the X Window system defines, which is widely available on Unix hosts. In this system of X resources, you can, for example, code foreground red, which means characters will appear in red.
X resources has a reputation for being inscrutably complex, mostly because it makes simple ideas very flexible in an unsystematic way. For example, you can assign foreground red in at least a half dozen modes so that it will apply only in a specific application, only for a specific user, only for a particular invocation of an application, and so on. The Tk option database's interface was derived from that complex set of interfaces.
One aspect of the Tk is taken from .Xdefaults, a configuration file located in a Unix $HOME directory, as is .mailrc or .login. Its syntax is a simple list of resource assignments, one on each line. A very small .Xdefaults file might look like:
*fontMenu*background: green
*foreground: black
We mentioned in our previous column that Tk under Unix is, among other things, a well-behaved X application. Therefore, Tk launched from Unix can be trusted to read .Xdefaults. From within Tk, you can programmatically inspect the pertinent resources assigned there. The [option get] subcommand does this:
# Assume .Xdefaults has the content listed above.
set value [option get . foreground ""]
puts "'value' now holds the value 'black': $value."
Moving beyond Unix
Most readers of this column probably use Windows systems from time to time. Windows has no standard for interpretation of .Xdefaults; however, Tk supports the [option readfile] subcommand on all platforms. That gives Windows a portable way to specify a resource configuration, as in:
set filename [file join $env(HOME) .Xdefaults]
option readfile $filename
Because Tk has already read $HOME/.Xdefaults, execution of that fragment under Unix is redundant. On Windows, though, those lines read C:\.Xdefaults and make the same initializations a Unix host would have read.
That illustrates why we're careful when we write about "portability." .Xdefaults is naturally meaningful on one OS, but not another. How should a portable language process a file that doesn't exist on most platforms? Tk's answer to that question has two parts. First, Tk behaves as a normal X application under Unix. Default actions are what a Unix user expects there. Second, the option command provides a cross-platform layer that enables you to write option-database code that is simultaneously portable and maintainable. You can choose to configure and use .Xdefaults in a portable way, and Tk does its part to make that possible.
