Author: Bryan Oakley <boakley@austin.rr.com>
State: Withdrawn
Type: Project
Vote: Pending
Created: 27-Jun-2001
Tcl-Version: 8.5
Post-History:
Abstract
This TIP proposes to add support for the ability to change the default list of bindtags for a class of widgets.
Introduction
Bindtags are an extremely useful addition to the Tk toolkit. By modifying the bindtags for a given widget, enhanced bindings can be added, or default behaviors removed, without modifying actual bindings.
At present, the default bindtags for a widget are fixed. All widgets are created with the same default bindtags. If an application programmer wants to alter the bindtags for a widget, she must do so on a case by case basis.
By allowing the programmer to define their own default bindtags, one can leverage the power of bindtags with fewer lines of code. In addition, changing the default bindtags can not only affect all widgets in a block of code, but widgets that are created at runtime, even if created by imported packages that are beyond the programmer's control.
Specification
An enhancement to the bindtags command is suggested. At present, the only valid use of bindtags is to include a widget name as the first argument. Therefore, adding a new parameter that does not begin with a dot will not break any existing scripts (that is to say, any script that presently has the command bindtags default is broken).
This TIP proposes the following enhancement to the bindtags syntax:
bindtags default class tagList
default is the literal name of a subcommand
class is a widget class (e.g. Listbox, Text, etc) or * to signify all classes. A default for a specific class will override the default for all.
tagList is a Tcl list of bindtags, with support for the following meta-characters, ala bind:
%C: the widget class
%W: the widget path for a specific instance of a widget
%%: replaced with a single %
For example:
bindtags default Text [list Special %W %C . all]
=> Special %W %C . all
text .t
=> .t
bindtags .t
=> Special .t Text . all
If tagList is null (e.g. bindtags default Text {}), the default bindtag reverts to the existing behavior. Because of this it is not possible to associate a null bindtag list to a widget, but it's doubtful that would ever be an issue. One could just as easily associate a bogus bindtag that has no bindings to get the same result. (As an alternate suggestion, we could allow null bindtag lists, and use bindtags default Text without a tagList to specify that the core defaults be used).
When a widget is created, its default bindtags will be those specified by the programmer via the enhanced syntax. If no defaults have been specified, the current behavior will be used. For widgets that take a -class parameter (e.g. frames), it will choose the bindtags based on its requested class rather than its base class. For example, frame .foo -class Combobox will use the bindtags for the class Combobox rather than the class Frame.
Rationale
Occasionally it is desirable to add a special bindtag to the front or end of the bindtag list for all widgets in an application. Or, one way want to replace the widget class bindtag with their own or remove it altogether. Without a way to specify a default, a programmer must issue a bindtag command for every widget after it is created. This has an impact on overall performance. In addition, it can be a source of errors over time; if a new programmer begins work on a project, she may not realize that widgets need this new bindtag and fail to add it in her code.
In addition, when widgets are created dynamically during the course of a user's interaction with the system (for example, when a dialog is created before it is popped up), the bindtags must be added at runtime. Often this is impractical if the dialog or widget(s) belong to an imported package that the programmer can't modify.
Alternatives to this TIP
An alternative way to implement this TIP might be to modify each widget command such that it becomes configurable. An example might be:
button configure -bindtags {Special %W %C . all}
=> Special %W %C . all
button .foo
=> .foo
bindtags .foo
Special .foo Button . all
Given that the widget commands now have no notion of class-level configuration values, it seems awkward to introduce it at this time. It would, however, open up the door for adding other features in future versions of Tk. I can envision, for example, button configure -renderer myButtonRenderProc, which would call myButtonRenderProc to render button widgets instead of using the default C-based renderer. This might make it possible to support a pluggable look and feel some day.
Keeping all of the bindtags interaction with the bindtags command seems like a better way to go.
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 great vigor.