<< Prev | - Up - | Next >> |
GTK+ is organized into visual units called widgets. Some widget classes are defined by refinement of some parent widget class using inheritance. Therefore, GTK+ has an object-oriented organization and maps nicely to the Oz object system.
Overview
The general steps to create a GTK+ widget are:
Instantiate a widget object using the appropriate constructor.
Connect appropriate handlers to all signals and events we wish to react to.
Set attributes of the widget.
Pack the widget into a container.
Make the widget visible.
A widget object is created by instantiating a widget class. The constructors are the methods starting with new
; some widget classes have multiple constructors. For example,
Button = {New GTK.button
newWithLabel("Hello, World!")}
creates a new object for a button labelled "Hello, World!"
.
Object creation yields a freshly created widget object whose attributes are set to reasonable default values. (It will not appear on the screen until it has been packed into a container which then is made visible.) The operations on the widget and its parent classes are available through the object's methods.
GTK+ is event-driven, which means that when an event occurs, control is passed to the appropriate procedure or method.
Signals
Events in GTK+ are implemented through signals. (Note that these signals are unrelated to Unix system signals.) When an event occurs, such as the press of a mouse button, the appropriate signal will be emitted by the corresponding widget. Some signals are common to all widget classes, such as 'delete-event'
, while others are widget-specific, such as 'toggled'
for a toggle button.
Connecting Handlers
The signalConnect
method allows to catch signals and cause invocation of actions. For instance,
{
Widget
signalConnect(
Signal
Callback
?Id
)}
causes Callback
to be invoked each time that the signal named Signal
is emitted on Widget
. Id
is a unique identifier which can be used to manually emit the signal or to remove the handler.
Callbacks
Callback
can be either a unary procedure or the label of a unary method. Thus, callbacks are either defined as a procedure:
proc {MyCallback Args}
...
/* Computations */
...
end
or as a method:
meth myCallback(Args)
...
/* Computations */
...
end
where Args
is a list of the arguments associated with the signal.
Low-level Events
In addition to the high-level signals described above, there is a set of events that reflect the X Window System event mechanism (simulated non-X platforms such as Windows). These can be caught using the special signal 'event'
. For more details, see Chapter 4.
GTK+ widgets organize their data using attributes. Some attributes are read-only, others are mutable. The latter allow for the widget to be reconfigured after creation.
Attributes are named by strings and have an associated (typed) value. Many widgets define accessors for commonly used attributes, but in general they can be read using the get
method and written to using the set
method. Trying to access a non-existing attribute yields an error.
Widgets are laid out on the screen using so-called containers. Container widgets themselves usually do not provide any visible information, but display their child widgets according to a built-in strategy. For example, an hBox
container will align its children horizontally on the screen. A container can contain other container widgets.
GTK+ provides a variety of different container types covering the ``daily'' needs, which all are descendants of the GTK.container
class. In the case of our ``hello world'' example, the GTK.window
class is the container the button is assigned to.
Bins
GTK.window
is a subclass of GTK.bin
, which is the superclass of all containers accepting at most one child. Bins do not do any layouting. If our window had contained more than one child, we would have needed to create another container to lay out the children, which would then have been the window's single child.
The last step to start working with widgets on the screen is to make them visible. This can be done manually by a bottom-up traversal of the container tree and calling each container's show
Method. This is what the topmost container's showAll
method does automatically.
With few exceptions, signals emitted by a widget are only caught while it remains visible.
GTK+ widgets do a lot of error-checking internally, but errors are just reported to the screen instead of being raised as an Oz exception. Errors discovered in the language binding's code are reported as exceptions.
<< Prev | - Up - | Next >> |