TIP:            39
Title:          Add New Standard Tk Option: -component
Version:        $Revision: 1.5 $
Author:         Bryan Oakley <boakley@austin.rr.com>
State:          Withdrawn
Type:           Project
Vote:           Pending
Created:        04-Jul-2001
Post-History:   
Keywords:       compound,megawidget
Tcl-Version:    8.5

~ Abstract

This TIP proposes to add a new standard option, ''-component'', for
all Tk widgets.

~ 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:

| frame .f -class LabelledEntry 
| entry .f.e -component .f
| label .f.l -component .f

Internal commands that act upon widgets could use this information to
alter their behavior for component widgets.  For example,
''tk_focusNext'' and ''tk_focusPrev'' could ignore components when
figuring out where to send focus, typically as a result of the user
pressing <Tab> or <Shift-Tab>.  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, ''-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.

~ Specification

Suggested wording for the ''options'' man page:

| Command-Line Name: -component
| Database Name: component
| Database Class: Component

 > ''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"''

In addition, ''tk_focusPrev'' and ''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.

~ 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.

~ 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 with unabashed hope 
for a brighter future.

