Purpose: describe what the term ''widget'' means ---- A ''widget'' is a term used in graphical user interface ([GUI]) circles in connection to some component of a GUI application. While most widgets have the potential of visual representation, this need not be the case - for instance, container widgets like frames don't actually show up on the screen. See [Tk syntax help] for a list of [Tk] specific commands, some of which are widgets: * [button] * [canvas] * [checkbutton] * [entry] * [frame] * [label] * [labelframe] * [menu] * [menubutton] * [message] * [panedwindow] * [radiobutton] * [scale] * [scrollbar] * [spinbox] * [text] ---- Note that in Tk, one has several ways one can control visual aspects of widgets: * externally, via the X resource database * at creation time, on the ''command line'' * later, using the ''-config'' option * via the [option] database * in some cases, via special objects, like [font] [[are there other ways of influencing these?]] ---- Some systems call these "controls." I've also heard "gadgets." -- CLN '''EE''': From '''The X Window System: Programming And Applications With Xt, OSF/Motif Edition''' by Douglas A. Young. (First edition, sixth printing, published in 1990): In addition to widgets, Motif provides a user interface component known as a gadget. Gadgets are identical to widgets, except that they have no [window] of their own. A gadget must display text or graphics in the window provided by its parent, and must also rely on its parent for input. [[...]] From the application programmer's viewpoint, gadgets can be used exactly the same way as other display widgets, except for the following restrictions. Gadgets cannot support event handlers, translations, or popup children. Gadgets can support callback functions and have the same appearance as the corresponding widgets. Widgets are a part of [Tk] as well as alternatives. ''[DKF] 17Dec02 -'' For a more modern example of the difference, Java Swing is almost entirely gadget-based, whereas AWT is pretty-much completely widget-based (though they use different terminology: lightweight and heavyweight Components.) ---- One must be certain to keep some things in mind when writing widget code. * Widget names are generally a series of period seperated names. [[Can someone write more text here concerning the naming of widgets, naming hierarchy and what is for, how it contrasts with namespaces, etc.]] * If your widget names might have spaces in them, be certain to treat the names carefully, in particular when using [eval], [subst], etc. * [DKF] writes in comp.lang.tcl: It's also not a good idea at all to start a widget name part with a capital letter (because that style of name is reserved for the names of widget classes, and you *really* don't want to get those two mixed up.) But it's usually really easy to start with a lower-case letter and use alphanumeric for the rest... * [Jeff Hobbs] writes in comp.lang.tcl: [[Using :: as characters in a widgets name as a]] problem is much more difficult to get around for megawidget authors than the space one. Properly treating things as lists solves the space problem. However, the use of namespaces for megawidget building is common in order to encapsulate code / hide the ickies from the user. That conflicts with the use of ::. It is possible to rename the :: parts when you use namespaces, but then it becomes cumbersome to map back and forth. [RS] As each widget defines a command with its name, can't interp aliases be used to map fancy to real names? E.g. interp alias {} foo::bar {} .top.frame1.bar.canvas ---- [LV] So, if someone has a string that they are ''certain'' is a name of a widget, is there introspection that can be used to determine '''what''' widget it is? ''[escargo] 16 Aug 2005'' - I would expect ''[winfo] exists'' should be able to answer that question. [LV] winfo exists just tells me if the widget exists - not what kind of a widget it is. Thanks! [MG] How about ''[winfo] class $widgetName''? [LV] That seems like it should work - thanks! ---- There is actually a [Tk] [extension] named '''widget''' as well. Written by [JH], it is a Tk [megawidget] [framework] (found at [MegaWidget package]). [tklib] now has a '''widget''' module [http://tcllib.cvs.sourceforge.net/tcllib/tklib/modules/widget/], also authored by [JH], which is to contain a variety of megawidgets. The initial ones are [snidgets], but the creator of the tklib widget module says that megawidgets in other OO packages... say [XOTcl] ... are also possible. [tklib] can be found in [ActiveTcl]. The '''widget''' package It is designed to use [tile] throughout. http://tcllib.sourceforge.net/doc/widget.html tklib's widget package contains the following [megawidget]s: * dialog ((a)synchronous dialog shell with core dialog handling) * menuentry (entry with dropdown menu) * panelframe * ruler * screenruler (this is cool, really!) * scrolledwindow * statusbar (for easier handling of bottom status items, with corner resize control) * superframe * toolbar Right now, I'd just like to see people start contributing widgets to tklib ;-) ... [ABU] 25-Jan-2006 I'd like to see documentation and demos - in general, many tklib modules are not well documented :-( [LV] What a wonderful opportunity to contribute back to the Tcl community in cases where people fear their [C] skills are lacking! Contributing first cuts at documentation and demos and test cases at least provide a point where another can submit additions and corrections. ''[escargo] 29 Apr 2006'' - You could make an entry in [Volunteer opportunities] for that. ----- [RS] 2006-04-28: Here's a little helper to retrieve the default value of a widget attribute (use long names (-background) instead of the short ones (-bg)): % proc get'default {w flag} {lindex [$w config $flag] 3} % get'default $t -font {MS Sans Serif} 8 The current value is of course returned by the ''cget'' method: % $t cget -font Courier 9 ---- [Blinking widgets] [Widget tags] [XPS] ----- !!!!!! %| [Category GUI] | [Category Data Structure] | [Category Concept] | [Category Glossary] | [Category Widget] |% !!!!!!