\documentclass[]{article}
\usepackage{amsmath,graphicx,supertabular,hyperref,tabularx,ifthen}
\title{TIP \#349: New "-cargo" option for every Tk widget}
\date{April 17, 2009}
\author{Zbigniew Baniewski}
\urlstyle{sf}
\setlength{\parskip}{1ex}
\setlength{\parindent}{0pt}
\def\tipversion$#1${\texttt{\$#1\$}}
\def\tiplangle#1{\ensuremath{<}}
\def\tiprangle#1{\ensuremath{>}}
\def\tipbar#1{\ensuremath{|}}
\def\tipmail#1#2{\(\langle\){\small\expandafter\url{#1@#2}}\(\rangle\)}
\ifx\pdfoutput\undefined
\newcommand{\tipimage}[2]{\typeout{Make sure you download #1.eps}\ifthenelse{\lengthtest{0.8\textwidth>#2}\and\lengthtest{0pt<#2}}{\includegraphics{#1.eps}}{\includegraphics[width=0.8\textwidth]{#1.eps}}}
\newcommand{\tipxref}[1]{}
\newcommand{\tipxrefend}{}
\else
\newcommand{\tipimage}[2]{\typeout{Make sure you create #1.pdf}\ifthenelse{\lengthtest{0.8\textwidth>#2}\and\lengthtest{0pt<#2}}{\includegraphics{#1.pdf}}{\includegraphics[width=0.8\textwidth]{#1.pdf}}}
\pdfcatalog{/PageMode /UseOutlines}
\newcommand{\tipxref}[1]{\pdfannotlink attr {/C [0.5 0.5 1.0] /Border [0 0 1]} goto name {#1}}
\newcommand{\tipxrefend}{\pdfendlink}
\fi
\newenvironment{tipabstract}{\begin{abstract}}{\end{abstract}}
\begin{document}\maketitle
\begin{center}\begin{tabularx}{\linewidth}{|r@{: }X|}\hline
\textbf{TIP \#349}&\textbf{New "-cargo" option for every Tk widget}\\\hline
Author&

Zbigniew Baniewski \tipmail{zb}{ispid.com.pl}
\\
Created&Friday, \(\text{17}^{\text{th}}\) April 2009\\
Type&Project\\
Tcl Version&\(8.7\)\\
State&Draft\\
Vote&Pending\\
Version&\tipversion$Revision: 1.1 $\\
Post History&\\
\hline\end{tabularx}\end{center}
\thispagestyle{empty}\pagestyle{empty}
\begin{tipabstract}

This TIP proposes adding a \textbf{-cargo} option to every Tk widget that will be kept free for code that uses the widget to use as it sees fit; the Tk library will assign no interpretation to the option.
\end{tipabstract}
\tableofcontents\setcounter{page}{0}\clearpage\pagestyle{plain}

\section{Proposal}

TCL users have long been at a disadvantage not having a possibility to attach arbitrary widget-related values (e.g., ``tooltip''-texts) directly to widget, being forced to use workarounds (e.g. external variables to hold the data) or even entire additional packages/frameworks (like Snit) exactly because of the lack of the proposed option.

So the proposal is ``solutions instead of workarounds'': let's introduce the option --- further named ``-cargo'' (the name taken from Clipper) --- which will cancel the current need for fixes of different kind. The option should allow to access a string field (or even better: a dictionary), allowing to keep there any widget-related data, choosen by script creator. It's value should be accessible both by ``cget'' and ``percent substitution'' (like ``\%C'').

\section{Rationale}

In a talk at \url{news:comp.lang.tcl} everyone --- or almost everyone --- posting in the appropriate threads, appreciated the proposed solution as useful. There were some fears about possible ``clashes'' while using that option (or that the proposed option will be even ``too useful''). I would to mention here, that ``cargo'' idea has been taken from Clipper, where --- during over 20 past years --- there is no evidence at all of any ``clashes'' (neither of any other damage) only because of availability of such option. Being sure, that TCL programmers aren't less skilled than those Clipper guys, I cannot describe such fears differently, than as not reasonable ones.

So because such option has been successfully tested in other language (there are no complaints from Clipper programmers about any ``cargo''-harmness), there's no need for ``prophecies'' of the type ``it will do damage'', because there has been proved exactly the contrary.

Some more possible usage gave Bryan Oakley in his post:

\begin{quote}
What sort of data would I potentially keep with a widget? Perhaps an index that points to context sensitive help. Or, I might keep an undo stack, or a copy of the original value. Think of a label widget that automatically truncates it's text and adds ``...'' if the widget is resized smaller than it's preferred size -{}- you need to keep the unadulterated original value that you can refer to as the widget grows and shrinks. Better to keep that with the widget than in a global variable, IMO. Or, I could use it to keep track of a ``dirty'' bit that gets set when the original value of a radiobutton or checkbutton changes. Or I could store a database primary key that points to where the data for the widget came from.
\end{quote}

I believe, that's not all, because we cannot predict today, what other useful things can be done with option of such ``universal'' (not ``targetted'') nature. Two things for sure: a) It'll make the life of every TCL-scriptor easier, b) Its use won't be obligatory, if someone will be afraid of ``clashes'' possibility, or something like this.

\section{License}

This document has been placed in the public domain.

\section{Colophon}

\textit{TIP AutoGenerator --- written by Donal K. Fellows}
\end{document}
