# TIP 42: Add New Standard Tk Option: -clientdata
Author: Bryan Oakley <[email protected]>
State: Withdrawn
Type: Project
Vote: Pending
Created: 05-Jul-2001
Post-History:
Tcl-Version: 8.5
-----
# Abstract
This TIP proposes to add a new standard option, -clientdata, for all
Tk widgets.
# Rationale
Many modern and not so modern widget toolkits provide a way to attach
programmer defined data to a widget. Tk lacks such a feature. The
only way to accomplish a similar feat today is by storing data in a
global or namespace variable keyed by widget name. This doesn't lend
itself very well to general purpose library routines.
One example of how this could be used is in prototyping additional
widget functionality. For example, [[39]](39.md) requests a new option for
each widget that enables a widget to declare that it is part of a
larger compound widget. One potential use of this new flag is in the
Tk library code that handles keyboard traversal.
With the option proposed in this TIP, it would have been quite simple
to prototype the necessary changes at the script level, making it
easier to validate the utility of the requested change in TIP \#39, and
to provide a reference implementation of the affected library
procedures.
Another example use of this flag would be in the development of a
graphical interface builder such as SpecTcl or Visual Tcl. With
applications that let you create widgets interactively, it is often
convenient to attach metadata directly to the widget. For example,
the tool might allow a user to enter comments about a given widget;
or, perhaps the tool provides a way to clone a widget and wants to
maintain the relationship by storing the name of the original widget.
It seems to make sense to keep this information with the actual widget
rather than in a global array.
A third example is that a widget or dialog could use this field to
store history information. For example, a file selection dialog could
remember the last directory it visited. An entry widget could
remember previous values for some sort of undo functionality.
Individual widgets could keep their default and most recent values to
support "revert" or "default" buttons in a form.
... and the list goes on. The bottom line is, it adds flexibility
that can be leveraged in many ways. Impact on the core is minimal
since it merely requires the storage and retrieval of information.
And the mechanism is already in place; we merely need to define a slot
in the widget data structure to store the information.
# Specification
Suggested wording for the _options_ man page \(which, I suspect, can
be greatly improved upon\):
Command-Line Name: -clientdata
Database Name: clientData
Database Class: ClientData
> _Specifies programmer defined data to be associated with the
widget. The Tk libraries do not use this information or require
the information to be in any particular format. It is purely for
use by the application._
# Lame Joke
Did you hear the one about the three legged dog that went into a
saloon, jumped up on the nearest stool, banged his good foot on the
bar, and with a steely-eyed glare said "I'm lookin' for the man that
shot my Paw!"?
# Notice of Withdrawal
This TIP was Withdrawn by the TIP Editor following discussion on the
tcl-core mailing list. The following is a summary of reasons for
withdrawal:
> Perhaps some of the ideas behind these TIPs should be incorporated
into some new TIP on making megawidget support better, but none of
these TIPs really stand on their own. \(38 isn't a good idea, since
alteration of the bindtags for all widgets of a class at once is a
bad idea, and it is better when rolling your own megawidget classes
to put the setting up of the bindtags in there. 39 and 42 just
clash with each other as soon as you have two different codebases
trying to use a single widget.\)
# Copyright
This document has been placed in the public domain accompanied with
only a small and very personal amount of fanfare.