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
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 or
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 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 )
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