constructor {args} { installhull $win $self configurelist $args }This kind of widgetadaptor must be created when the hull widget already exists; when the widgetadaptor's instance is created, the existing widget suddenly gets new methods and/or options and functions.It turned out to be very effective to design necessary addons for a particular widget type as independent pieces, implementing only a well-defined, highly-specialized function in each widgetadaptor. When you need some combination of those extensions in your application, it will be easy to write something like that:
undoable [autocontextmenu [filecompletion [entry $path.ent]]]where undoable, autocontextmenu and filecompletion is a name of your widgetadaptors adding miscellaneous features to an entry.There's more than that. When you'll need to adapt a widget that is not an entry, but is much like an entry, no change in the widgetadaptor will be required usually:
undoable [ttk::combobox $path.myCombobox](I actually have an "undoable" adapter for entries that runs unmodified with tile entries and various comboboxes).Having a toolbox of widgetadaptors that don't enforce any predefined hull type is much like working with Unix environment. You don't have to choose between ls with integrated awk scripting and tcl interpreter and another ls that reads zip archives but lacks builtin awk: every tool does its own job, and they all are easily combined when a complex job must be done.
NEM: See also Traits which take a similar approach to composing objects.
ABU 13-feb-2006Thanks to A/AK for his enlightening discussion. Here are some links about my work with widgetadaptors:
WHD - 2009-09-28 14:24:39Very cool. I don't tend to do this kind of thing because I worry about performance; each widget adds another layer of wrapping, and it slows things down. But computers are a lot faster now than I first wrote Snit, and maybe I worry too much. :-)
A/AK - 2009-09-29 04:42:00 MSKI used to worry about performance as well, but with snit2 based on namespace ensemble method dispatching is much faster than before. Once a delegated method is called, it stays in the object's method cache, and in the case of ensembles it means that no TCL code is involved in dispatching it on all further calls. If there were even twenty redirections of this kind, I think it still won't add any significant performance penalty (with snit2 and tcl8.5+).
WHD - 2009-09-30 14:47:04That was the intent; it's nice to know that it's worked out in practice.