Author:         Bryan Oakley <boakley@austin.rr.com>
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] 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