Author: Bryan Oakley <email@example.com> State: Withdrawn Type: Project Vote: Pending Created: 04-Jul-2001 Post-History: Keywords: compound,megawidget Tcl-Version: 8.5
This TIP proposes to add a new standard option, -component, for all Tk widgets.
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
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.
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.
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.)
This document has been placed in the public domain with unabashed hope for a brighter future.