\documentclass[]{article}
\usepackage{amsmath,graphicx,supertabular,hyperref,tabularx,ifthen}
\title{TIP \#39: Add New Standard Tk Option: -component}
\date{July 04, 2001}
\author{Bryan Oakley}
\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 \#39}&\textbf{Add New Standard Tk Option: -component}\\\hline
Author&

Bryan Oakley \tipmail{boakley}{austin.rr.com}
\\
Created&Wednesday, \(\text{4}^{\text{th}}\) July 2001\\
Type&Project\\
Tcl Version&\(8.5\)\\
State&Withdrawn\\
Vote&Pending\\
Version&\tipversion$Revision: 1.5 $\\
Keywords&compound, megawidget\\
Post History&\\
\hline\end{tabularx}\end{center}
\thispagestyle{empty}\pagestyle{empty}
\begin{tipabstract}

This TIP proposes to add a new standard option, \textit{-component}, for all Tk widgets.
\end{tipabstract}
\tableofcontents\setcounter{page}{0}\clearpage\pagestyle{plain}

\section{Introduction}

One of the problems with creating compound widgets (or ``megawidgets'') in Tk is library code that doesn't know whether a widget is a widget or whether it is merely a component of a larger compound widget.

This TIP suggests a new common option for all widgets that defines whether a widget is merely a component of a larger compound object. The value of this option would normally be the empty string, but could be set to the name of a widget that is the ``root'' of a compound widget (typically a component window's parent).

For example, consider a prototypical labelled entry widget that is made up of a frame (.f), and entry widget (.f.e) and a label (.f.l). These might be defined as follows:
\begingroup\small\begin{verbatim}
 frame .f -class LabelledEntry 
 entry .f.e -component .f
 label .f.l -component .f
\end{verbatim}
\endgroup

Internal commands that act upon widgets could use this information to alter their behavior for component widgets. For example, \textit{tk\_focusNext} and \textit{tk\_focusPrev} could ignore components when figuring out where to send focus, typically as a result of the user pressing \tiplangle{}Tab\tiprangle{} or \tiplangle{}Shift-Tab\tiprangle{}. This would help sole a nagging problem with many compound widgets.

We might want to modify [winfo children] to ignore component windows as well (unless, for example, \textit{-showcomponents} is set to true), only reporting those children added by external entities. For example, consider a compound widget that implements a scrollable container. This widget might be built with a frame (.f), a vertical scrollbar (.f.v) and a horizontal scrollbar (.f.h). After a user adds their own widgets to this window they would expect [winfo children .f] to return only the windows they created, and might be confused (or at least annoyed) by the presence of these internal windows.

\section{Specification}

Suggested wording for the \textit{options} man page:
\begingroup\small\begin{verbatim}
 Command-Line Name: -component
 Database Name: component
 Database Class: Component
\end{verbatim}
\endgroup

\begin{quote}
\textit{Designates that this widget is a component of a larger widget. This option is normally the empty string. If it is not the empty string, it should be set to the ``root'' of the compound widget. For example, if a compound widget is made up of frame ``.f'' and an entry widget ``.f.e'', the latter will have as it's component value ``.f'' designating that it is a component of the compound widget rooted at ``.f''}
\end{quote}

In addition, \textit{tk\_focusPrev} and \textit{tk\_focusNext} should take the value of this flag into consideration when determining where focus should next be given (i.e. it should not give focus to components; focus should be given to root widgets, which shall be responsible for redirecting focus as required).

Once this TIP gets implemented, subsequent TIPs can be produced to define how additional Tk library functions and commands can be modified to take advantage of this new information.

\section{Rationale}

We need a standardized way of determining whether a widget is an atomic object or part of a larger compound object. This has several uses, the most obvious (to me, anyway) being focus management.

\section{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:

\begin{quote}
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.)
\end{quote}

\section{Copyright}

This document has been placed in the public domain with unabashed hope for a brighter future.

\section{Colophon}

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