User interface widgets

\c{ The Tk toolkit offers numerous built-in widgets. The Tk widgets conform to the look-and-feel of the OSF/Motif standard. The hush C++ interface for Tk provides for each Tk widget a class of the same name, which supports the creation of a widget and allows the user to access and modify it. In addition to the standard Tk widgets, the hush library integrates a number of other widgets, such as a barchart, hypertext, and photo widget (created by other Tk adepts). Also some others widgets are offered, such as a filechooser widget. In section new it will be explained how to create new widgets in C++ and make them available for use in a Tcl script. In this section only a limited number of the available widgets will be described.\ftn{ For additional widgets the user is referred to the manual pages accompanying hush. }

Pathnames

When creating an instance of a widget a path name must be given. In order to allow for a more flexible naming scheme, for each widget class a second constructor has been provided that has a widget pointer as its first parameter. This widget acts as the parent of the newly created widget.\ftn{ Currently, the child widget must explicitly be packed. However, this may change in the future. } The path name of the newly created widget will be the concatenation of the path name of the (parent) widget and the path name given as the second parameter.

Options

Both constructors allow for an options parameter which may be used to set the options for the widget as defined for Tk. The functions provided for each widget class are merely meant to provide convenient access to the Tk widgets. More demanding programmers may use the constructor options parameter, or the widget::eval or widget::configure functions instead.

Creation and inheritance

To accommodate the use of inheritance to redefine the behavior of widgets or to create compound widgets, the constructors take apart from the options parameter a boolean flag (which is default set to true). If the flag is set to false, the initialization code for a widget will not be executed. Apart, from omitting initialization in the context of inheritance, the user may also wish to omit the initialization to create a reference to an already existing widget. We will not display the boolean flag parameter in the widget interfaces shown here. When a widget class does not correspond to a widget supported by Tk, mostly an additional constructor will be defined that is used to create a handler to deal with the creation of such widgets in Tcl scripts. For an example, see section new.

Handlers

For a number of widgets a handler may be defined. A handler, in this context, is an action associated with the events related to the default bindings for the widget. Do not confuse the handler function defined for a widget object with handler objects that may be used to define an action. The widget::handler function may itself be given a handler object as parameter. An example of a command function that may be installed as a handler for a widget (by means of widget::handler) is the function browse defined below. } .so browse \c{ The browse function assumes that a widget has been defined as a client. It simply prints the type and the path name of the widget, and in addition the arguments given when calling the action related to the function. Widgets for which the declaration of a handler is meaningful are assumed to have a protected member function install defining the default bindings. Naturally, the function browse may also be used to define the action related to a user-defined binding. } .so button .so menu .so dialogs