TIP 39: Add New Standard Tk Option: -component

Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2017 Conference, Houston/TX, US, Oct 16-20
Send your abstracts to tclconference@googlegroups.com
by Aug 21.
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 or . 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.

History