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.

Full complement of subcommands

A different subcommand, [option add], gives still another slant on portability. Suppose we drop .Xdefaults entirely. Under Unix it's certainly possible to launch an X-based application with no .Xdefaults; the options database would simply be empty. Such an application could still be configured, though. Tk applications on any platform can interpret

    *fontMenu*background: green

		 *foreground: black    

as Tk source code to give the same result as our .Xdefaults example.

Let's summarize all this in terms of source-code architecture. Suppose we want to set the font of all our entry widgets to times 12 bold. We might write:

    entry $widget -font {times 12 bold} ...

for each entry we create. The redundancy of repeating the font specification in several places makes maintenance fragile.

One approach we often take in our development work to combat this problem is to create an "entry factor":

    proc make_entry {widget ...} {

        set font {times 12 bold}

		 entry $widget -font $font ...

    }

We can also go in an even more declarative direction and initialize the source code with:

    option add *Entry.font {times 12 bold}

Finally, we can externalize the declaration entirely, by using option readfile and a separate file with contents:

    *Entry*font: times 12 bold

Each of those four choices is entirely portable. Decide among them by considering the overall architecture of your application. If you're dashing off a tiny prototype, coding the font specification inline each time you need it -- as the first choice above does - is probably quickest. If you have several applications, each in use by several people, and you need uniformity of appearance across applications and users, even option readfile won't exhaust the option database's capabilities.

As we explained previously, you have several supplementary ways to set resources with Unix OSs. Until then, have fun making your GUIs more consistent and maintainable with the option database.

Resources

» posted by ITworld staff

Unix Insider

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine