Individualize Your Apps

SAN FRANCISCO (06/07/2000) - Most GUI toolkits provide several ways to configure such widget characteristics as color, font, and size. For the first installment of this month's column, we'll look specifically at the Tk toolkit and its option database.

Tk is quite portable, so the examples here work under Apple Computer Inc.'s Mac OS, Unix, and Microsoft Corp.'s Windows, among other operating systems. What's more, although these examples are coded in Tcl/Tk, each one can be adapted immediately for the related PerlTk, Tkinter (Python), TkLua, and other Tk-derived bindings.

Many successful Tk programmers are barely aware of the option database. Recent books by John Grayson, Nancy Walsh, and Chris Nelson have only a couple of pages each on this subject, although all three of these books capture the essentials accurately. This continues a tradition begun by Tk's author, John Ousterhout, who wrote in his 1994 book:

The option database shouldn't be needed very often in Tk applications because widgets have reasonable default values.... The option database exists primarily to provide cultural compatibility with other X toolkits; I suggest that you use it as little as possible.

Tk does indeed "have reasonable default values"; even beginners can build quite useful GUIs with Tk. After this column, though, you'll have a better grasp of how to advance beyond that level.

Not a database to fear

Don't be afraid of the option database. It's really just a small, flat configuration file. In other words, you can examine and update it as a simple text file, without the structural and transactional overhead of more formal databases. Here's a minimal example of an option database: a file in your Unix $HOME directory called .Xdefaults with contents:

*background: blue

In English, this says, "Make the default background color for all my widgets in all my X applications, including Tk applications, blue." The format and interpretation of option databases are portable to Mac OS, OpenVMS, and Windows; the next installment of Regular Expressions will provide a few platform-specific tips to help start you off right if you're not using Unix.

More generally, an option database is a file that lists key-value pairs. With it, you can customize the appearance of an application without making any changes to the code for that application. A common example is a specification that cranks up the font size for widgets. Suppose you create a Tk-based application and deliver copies to hundreds of users. Everything's going great, until a couple of users complain that the text is too tiny. The option database answers their need with no requirement to alter your application, pass it through quality assurance again, redeploy it in separate versions, or any related complications. Instead, just instruct those users who want larger text to include the following line in their resource databases:

*font: {Courier 17}

Syntax of the database

Refinements of the basic key-value syntax give more precise control of screen appearance. The format is exactly that of X's resource database, which is familiar to many Unix users. The key is a multipart string to name the application, a widget to receive the new value, and an attribute. A colon and whitespace separate the key and value. Thus, a single line that says, "Make the background color of the buttons of all Tk applications cyan" appears in the options database as:

Tk.Button.background: cyan

Widget names can be wildcarded with *, so it's legal to write:

Tk*background: cyan

It's also possible to name specific widgets, so the option database might include the lines:

Tk.label1.background: white

Tk.label5.background: blue

As with widgets, the application name appears in one of three forms: the * wildcard; a specific application name; or a capitalized class name. The Tk immediately above is a class name. Any application built under Unix with Tk has the Tk class name.

An application name, on the other hand, specifies an executable instance. For example, when Tcl/Tk-based wish is run as a console application from the desktop, its application name might be wish83 (version 8.3 of wish). But when coauthor Flick launches his test-engine tool, it comes up with an application name of tapioca.

Database management

To this point, we've presented the option database in a Unix context as $HOME/.Xdefaults. As with most things X, there is an abundance of variations on this theme. Developers have a great deal of flexibility in specifying options to their Tk applications.

After a Tk application has begun, it can access an alternative option database under programmatic control with: option readfile $my_option_databaseIn this usage, $my_option_database names a file in exactly the format we've already described, but in an arbitrary position in the filesystem. This might be a systemwide configuration, as in: option readfile /usr/local/options/monitor.dbor one customized for a particular user, such as: set my_option_database /home/aflick/options/.games.db option readfile $my_option_databaseThere are two additional ways in which a script can control widget appearance with even finer programmatic control. The Tk option command also recognizes individual key-value elements with the add subcommand. This gives the possibility of sequences, such as: option add *Text.background green option add *foreground blackThe final alternative an options-database programmer needs to remember is the one generally taught first to Tk developers: programmatic control of the attributes of individual widgets. Attributes of a widget can be initialized at the time they're first created, such as: text .mytext -font {-family garamond size 24}They can also be reconfigured at any time during Tk's execution:

.mytext configure -font $a_better_font

Is your world all black and white?

It's a bit surprising that more programmers don't exploit the option database.

Our introduction aims to dispel the intimidating reputation it has apparently acquired. In our next column, we'll show you how to apply these principles to Windows and Mac OS. We will also discuss a few architectural concerns involved in distributing finished applications. Until then, bring color into your life: use the Tk option database!

About the author

Guest columnist Allen Flick is senior test engineer for InterVoice-Brite. He was the key developer of the Tapioca Tcl/Tk-based test engine used at DSC Communications, the company now known as Alcatel USA. Tapioca was presented to the San Diego Tcl/Tk Conference of September 1998.

Cameron Laird is vice president of Phaseit, Inc.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about Alcatel-LucentApple ComputerIntervoiceMicrosoftPhaseit

Show Comments