Commit 900944ab authored by BST 1999  Tony Gale's avatar BST 1999 Tony Gale Committed by Tony Gale

Style check from David King <dking@youvegotmail.net>

Fri Apr  2 09:19:20 BST 1999  Tony Gale <gale@gtk.org>

        * docs/gtk_tut.sgml: Style check from David King
          <dking@youvegotmail.net>
parent 57afb2b5
Fri Apr 2 09:19:20 BST 1999 Tony Gale <gale@gtk.org>
* docs/gtk_tut.sgml: Style check from David King
<dking@youvegotmail.net>
1999-03-30 Pavel Machek <pavel@artax.karlin.mff.cuni.cz>
* gtk/gtkfontsel.c (gtk_font_selection_get_fonts): Make code
......
Fri Apr 2 09:19:20 BST 1999 Tony Gale <gale@gtk.org>
* docs/gtk_tut.sgml: Style check from David King
<dking@youvegotmail.net>
1999-03-30 Pavel Machek <pavel@artax.karlin.mff.cuni.cz>
* gtk/gtkfontsel.c (gtk_font_selection_get_fonts): Make code
......
Fri Apr 2 09:19:20 BST 1999 Tony Gale <gale@gtk.org>
* docs/gtk_tut.sgml: Style check from David King
<dking@youvegotmail.net>
1999-03-30 Pavel Machek <pavel@artax.karlin.mff.cuni.cz>
* gtk/gtkfontsel.c (gtk_font_selection_get_fonts): Make code
......
Fri Apr 2 09:19:20 BST 1999 Tony Gale <gale@gtk.org>
* docs/gtk_tut.sgml: Style check from David King
<dking@youvegotmail.net>
1999-03-30 Pavel Machek <pavel@artax.karlin.mff.cuni.cz>
* gtk/gtkfontsel.c (gtk_font_selection_get_fonts): Make code
......
Fri Apr 2 09:19:20 BST 1999 Tony Gale <gale@gtk.org>
* docs/gtk_tut.sgml: Style check from David King
<dking@youvegotmail.net>
1999-03-30 Pavel Machek <pavel@artax.karlin.mff.cuni.cz>
* gtk/gtkfontsel.c (gtk_font_selection_get_fonts): Make code
......
Fri Apr 2 09:19:20 BST 1999 Tony Gale <gale@gtk.org>
* docs/gtk_tut.sgml: Style check from David King
<dking@youvegotmail.net>
1999-03-30 Pavel Machek <pavel@artax.karlin.mff.cuni.cz>
* gtk/gtkfontsel.c (gtk_font_selection_get_fonts): Make code
......
Fri Apr 2 09:19:20 BST 1999 Tony Gale <gale@gtk.org>
* docs/gtk_tut.sgml: Style check from David King
<dking@youvegotmail.net>
1999-03-30 Pavel Machek <pavel@artax.karlin.mff.cuni.cz>
* gtk/gtkfontsel.c (gtk_font_selection_get_fonts): Make code
......
......@@ -8,10 +8,10 @@
<title>GTK v1.2 Tutorial
<author>
Tony Gale <tt><htmlurl url="mailto:gale@gtk.org"
name="&lt;gale@gtk.org&gt;"></tt>
name="&lt;gale@gtk.org&gt;"></tt>,
Ian Main <tt><htmlurl url="mailto:imain@gtk.org"
name="&lt;imain@gtk.org&gt;"></tt>,
<date>February 21st, 1999
name="&lt;imain@gtk.org&gt;"></tt>
<date>April 1st, 1999
<abstract>
This is a tutorial on how to use GTK (the GIMP Toolkit) through its C
interface.
......@@ -38,7 +38,8 @@ now been used in a large number of software projects, including the
GNU Network Object Model Environment (GNOME) project. GTK is built on
top of GDK (GIMP Drawing Kit) which is basically a wrapper around the
low-level functions for accessing the underlying windowing functions
(Xlib in the case of X windows). The primary authors of GTK are:
(Xlib in the case of the X windows system). The primary authors of GTK
are:
<itemize>
<item> Peter Mattis <tt><htmlurl url="mailto:petm@xcf.berkeley.edu"
......@@ -54,10 +55,10 @@ interface (API). Although written completely in C, it is implemented
using the idea of classes and callback functions (pointers to
functions).
There is also a third component called glib which contains a few
There is also a third component called GLib which contains a few
replacements for some standard calls, as well as some additional
functions for handling linked lists etc. The replacement functions are
used to increase GTK's portability, as some of the functions
functions for handling linked lists, etc. The replacement functions
are used to increase GTK's portability, as some of the functions
implemented here are not available or are nonstandard on other unixes
such as g_strerror(). Some also contain enhancements to the libc
versions, such as g_malloc that has enhanced debugging utilities.
......@@ -94,14 +95,11 @@ understanding of C, and how to create C programs. It would be a great
benefit for the reader to have previous X programming experience, but
it shouldn't be necessary. If you are learning GTK as your first
widget set, please comment on how you found this tutorial, and what
you had trouble with. Note that there is also a C++ API for GTK
(GTK--) in the works, so if you prefer to use C++, you should look
into this instead. There are also Objective C, ADA, Guile and other
language bindings available, but I don't follow these.
you had trouble with. There are also C++, Objective C, ADA, Guile and
other language bindings available, but I don't follow these.
This document is a 'work in progress'. Please look for updates on
http://www.gtk.org/ <htmlurl url="http://www.gtk.org/"
name="http://www.gtk.org/">.
This document is a "work in progress". Please look for updates on
<htmlurl url="http://www.gtk.org/" name="http://www.gtk.org/">.
I would very much like to hear of any problems you have learning GTK
from this document, and would appreciate input as to how it may be
......@@ -113,20 +111,20 @@ name="Contributing"> for further information.
<!-- ***************************************************************** -->
<p>
The first thing to do of course, is download the GTK source and
The first thing to do, of course, is download the GTK source and
install it. You can always get the latest version from ftp.gtk.org in
/pub/gtk. You can also view other sources of GTK information on
http://www.gtk.org/ <htmlurl url="http://www.gtk.org/"
name="http://www.gtk.org/">. GTK uses GNU autoconf for configuration.
Once untar'd, type ./configure --help to see a list of options.
<htmlurl url="http://www.gtk.org/" name="http://www.gtk.org/">. GTK
uses GNU autoconf for configuration. Once untar'd, type ./configure
--help to see a list of options.
Th GTK source distribution also contains the complete source to all of
the examples used in this tutorial, along with Makefiles to aid
The GTK source distribution also contains the complete source to all
of the examples used in this tutorial, along with Makefiles to aid
compilation.
To begin our introduction to GTK, we'll start with the simplest
program possible. This program will create a 200x200 pixel window and
has no way of exiting except to be killed using the shell.
has no way of exiting except to be killed by using the shell.
<tscreen><verb>
/* example-start base base.c */
......@@ -155,10 +153,11 @@ You can compile the above program with gcc using:
gcc base.c -o base `gtk-config --cflags --libs`
</verb></tscreen>
The meaning of the unusual compilation options is explained below.
The meaning of the unusual compilation options is explained below in
<ref id="sec_compiling" name="Compiling Hello World">.
All programs will of course include gtk/gtk.h which declares the
variables, functions, structures etc. that will be used in your GTK
variables, functions, structures, etc. that will be used in your GTK
application.
The next line:
......@@ -200,10 +199,10 @@ The next two lines of code create and display a window.
gtk_widget_show (window);
</verb></tscreen>
The GTK_WINDOW_TOPLEVEL argument specifies that we want the window to
undergo window manager decoration and placement. Rather than create a
window of 0x0 size, a window without children is set to 200x200 by
default so you can still manipulate it.
The <tt/GTK_WINDOW_TOPLEVEL/ argument specifies that we want the
window to undergo window manager decoration and placement. Rather than
create a window of 0x0 size, a window without children is set to
200x200 by default so you can still manipulate it.
The gtk_widget_show() function lets GTK know that we are done setting
the attributes of this widget, and that it can display it.
......@@ -217,7 +216,7 @@ The last line enters the GTK main processing loop.
gtk_main() is another call you will see in every GTK application.
When control reaches this point, GTK will sleep waiting for X events
(such as button or key presses), timeouts, or file IO notifications to
occur. In our simple example however, events are ignored.
occur. In our simple example, however, events are ignored.
<!-- ----------------------------------------------------------------- -->
<sect1>Hello World in GTK
......@@ -278,7 +277,7 @@ int main( int argc,
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
/* When the window is given the "delete_event" signal (this is given
* by the window manager, usually by the 'close' option, or on the
* by the window manager, usually by the "close" option, or on the
* titlebar), we ask it to call the delete_event () function
* as defined above. The data passed to the callback
* function is NULL and is ignored in the callback function. */
......@@ -287,7 +286,7 @@ int main( int argc,
/* Here we connect the "destroy" event to a signal handler.
* This event occurs when we call gtk_widget_destroy() on the window,
* or if we return 'FALSE' in the "delete_event" callback. */
* or if we return FALSE in the "delete_event" callback. */
gtk_signal_connect (GTK_OBJECT (window), "destroy",
GTK_SIGNAL_FUNC (destroy), NULL);
......@@ -330,7 +329,7 @@ int main( int argc,
</verb></tscreen>
<!-- ----------------------------------------------------------------- -->
<sect1>Compiling Hello World
<sect1>Compiling Hello World <label id="sec_compiling">
<p>
To compile use:
......@@ -339,14 +338,14 @@ gcc -Wall -g helloworld.c -o helloworld `gtk-config --cflags` \
`gtk-config --libs`
</verb></tscreen>
This uses the program <tt>gtk-config</>, which comes with gtk. This
program 'knows' what compiler switches are needed to compile programs
that use gtk. <tt>gtk-config --cflags</> will output a list of include
This uses the program <tt/gtk-config/, which comes with GTK. This
program "knows" what compiler switches are needed to compile programs
that use GTK. <tt/gtk-config --cflags/ will output a list of include
directories for the compiler to look in, and <tt>gtk-config --libs</>
will output the list of libraries for the compiler to link with and
the directories to find them in. In the aboce example they could have
been combined into a single instance, such as
`gtk-config --cflags --libs`.
<tt/`gtk-config --cflags --libs`/.
Note that the type of single quote used in the compile command above
is significant.
......@@ -357,10 +356,10 @@ The libraries that are usually linked in are:
<item>The GDK library (-lgdk), the Xlib wrapper.
<item>The gmodule library (-lgmodule), which is used to load run time
extensions.
<item>The glib library (-lglib), containing miscellaneous functions, only
g_print() is used in this particular example. GTK is built on top
of glib so you will always require this library. See the section on
<ref id="sec_glib" name="glib"> for details.
<item>The GLib library (-lglib), containing miscellaneous functions;
only g_print() is used in this particular example. GTK is built on top
of glib so you will always require this library. See the section on
<ref id="sec_glib" name="GLib"> for details.
<item>The Xlib library (-lX11) which is used by GDK.
<item>The Xext library (-lXext). This contains code for shared memory
pixmaps and other X extensions.
......@@ -375,12 +374,15 @@ and callbacks. GTK is an event driven toolkit, which means it will
sleep in gtk_main until an event occurs and control is passed to the
appropriate function.
This passing of control is done using the idea of "signals". When an
event occurs, such as the press of a mouse button, the appropriate
signal will be "emitted" by the widget that was pressed. This is how
GTK does most of its useful work. There are a set of signals that all
widgets inherit, such as "destroy", and there are signals that are
widget specific, such as "toggled" on a toggle button.
This passing of control is done using the idea of "signals". (Note
that these signals are not the same as the Unix system signals, and
are not implemented using them, although the terminology is almost
identical.) When an event occurs, such as the press of a mouse button,
the appropriate signal will be "emitted" by the widget that was
pressed. This is how GTK does most of its useful work. There are
signals that all widgets inherit, such as "destroy", and there are
signals that are widget specific, such as "toggled" on a toggle
button.
To make a button perform an action, we set up a signal handler to
catch these signals and call the appropriate function. This is done by
......@@ -393,26 +395,26 @@ gint gtk_signal_connect( GtkObject *object,
gpointer func_data );
</verb></tscreen>
Where the first argument is the widget which will be emitting the
signal, and the second, the name of the signal you wish to catch. The
where the first argument is the widget which will be emitting the
signal, and the second the name of the signal you wish to catch. The
third is the function you wish to be called when it is caught, and the
fourth, the data you wish to have passed to this function.
The function specified in the third argument is called a "callback
function", and should generally be of the form:
function", and should generally be of the form
<tscreen><verb>
void callback_func( GtkWidget *widget,
gpointer callback_data );
</verb></tscreen>
Where the first argument will be a pointer to the widget that emitted
the signal, and the second, a pointer to the data given as the last
where the first argument will be a pointer to the widget that emitted
the signal, and the second a pointer to the data given as the last
argument to the gtk_signal_connect() function as shown above.
Note that the above form for a signal callback function declaration is
only a general guide, as some widget specific signals generate
different calling parameters. For example, the GtkCList "select_row"
different calling parameters. For example, the CList "select_row"
signal provides both row and column parameters.
Another call used in the <em>helloworld</em> example, is:
......@@ -427,13 +429,13 @@ gint gtk_signal_connect_object( GtkObject *object,
gtk_signal_connect_object() is the same as gtk_signal_connect() except
that the callback function only uses one argument, a pointer to a GTK
object. So when using this function to connect signals, the callback
should be of the form:
should be of the form
<tscreen><verb>
void callback_func( GtkObject *object );
</verb></tscreen>
Where the object is usually a widget. We usually don't setup callbacks
where the object is usually a widget. We usually don't setup callbacks
for gtk_signal_connect_object however. They are usually used to call a
GTK function that accepts a single widget or object as an argument, as
is the case in our <em>helloworld</em> example.
......@@ -448,7 +450,7 @@ data supplied to the callbacks.
<!-- ----------------------------------------------------------------- -->
<sect1>Events
<p>
In addition to the signal mechanism described above, there are a set
In addition to the signal mechanism described above, there is a set
of <em>events</em> that reflect the X event mechanism. Callbacks may
also be attached to these events. These events are:
......@@ -544,18 +546,18 @@ something like:
<tscreen><verb>
gtk_signal_connect( GTK_OBJECT(button), "button_press_event",
GTK_SIGNAL_FUNC(button_press_callback),
NULL);
NULL);
</verb></tscreen>
This assumes that <tt/button/ is a GtkButton widget. Now, when the
This assumes that <tt/button/ is a Button widget. Now, when the
mouse is over the button and a mouse button is pressed, the function
<tt/button_press_callback/ will be called. This function may be
declared as:
<tscreen><verb>
static gint button_press_event (GtkWidget *widget,
GdkEventButton *event,
gpointer data);
static gint button_press_callback( GtkWidget *widget,
GdkEventButton *event,
gpointer data );
</verb></tscreen>
Note that we can declare the second argument as type
......@@ -577,8 +579,8 @@ For details on the GdkEvent data types, see the appendix entitled
<!-- ----------------------------------------------------------------- -->
<sect1>Stepping Through Hello World
<p>
Now that we know the theory behind this, lets clarify by walking through
the example <em>helloworld</em> program.
Now that we know the theory behind this, let's clarify by walking
through the example <em>helloworld</em> program.
Here is the callback function that will be called when the button is
"clicked". We ignore both the widget and the data in this example, but
......@@ -601,7 +603,7 @@ some sort of response, or simply quit the application.
The value you return in this callback lets GTK know what action to
take. By returning TRUE, we let it know that we don't want to have
the "destroy" signal emitted, keeping our application running. By
returning FALSE, we ask that "destroy" is emitted, which in turn will
returning FALSE, we ask that "destroy" be emitted, which in turn will
call our "destroy" signal handler.
<tscreen><verb>
......@@ -636,7 +638,7 @@ int main( int argc,
{
</verb></tscreen>
This next part, declares a pointer to a structure of type
This next part declares pointers to a structure of type
GtkWidget. These are used below to create a window and a button.
<tscreen><verb>
......@@ -654,7 +656,7 @@ allowing your application to parse the remaining arguments.
gtk_init (&amp;argc, &amp;argv);
</verb></tscreen>
Create a new window. This is fairly straight forward. Memory is
Create a new window. This is fairly straightforward. Memory is
allocated for the GtkWidget *window structure so it now points to a
valid structure. It sets up a new window, but it is not displayed
until we call gtk_widget_show(window) near the end of our program.
......@@ -663,20 +665,20 @@ until we call gtk_widget_show(window) near the end of our program.
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
</verb></tscreen>
Here is an example of connecting a signal handler to an object, in
this case, the window. Here, the "destroy" signal is caught. This is
emitted when we use the window manager to kill the window (and we
return FALSE in the "delete_event" handler), or when we use the
gtk_widget_destroy() call passing in the window widget as the object
to destroy. By setting this up, we handle both cases with a single
call. Here, it just calls the destroy() function defined above with a
NULL argument, which quits GTK for us.
The GTK_OBJECT and GTK_SIGNAL_FUNC are macros that perform type
casting and checking for us, as well as aid the readability of the
code.
Here are two examples of connecting a signal handler to an object, in
this case, the window. Here, the "delete_event" and "destroy" signals
are caught. The first is emitted when we use the window manager to
kill the window, or when we use the gtk_widget_destroy() call passing
in the window widget as the object to destroy. The second is emitted
when, in the "delete_event" handler, we return FALSE.
The <tt/GTK_OBJECT/ and <tt/GTK_SIGNAL_FUNC/ are macros that perform
type casting and checking for us, as well as aid the readability of
the code.
<tscreen><verb>
gtk_signal_connect (GTK_OBJECT (window), "delete_event",
GTK_SIGNAL_FUNC (delete_event), NULL);
gtk_signal_connect (GTK_OBJECT (window), "destroy",
GTK_SIGNAL_FUNC (destroy), NULL);
</verb></tscreen>
......@@ -687,7 +689,7 @@ it 10 pixels wide where no widgets will go. There are other similar
functions which we will look at in the section on
<ref id="sec_setting_widget_attributes" name="Setting Widget Attributes">
And again, GTK_CONTAINER is a macro to perform type casting.
And again, <tt/GTK_CONTAINER/ is a macro to perform type casting.
<tscreen><verb>
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
......@@ -730,12 +732,13 @@ gtk_signal_connect().
GTK_OBJECT (window));
</verb></tscreen>
This is a packing call, which will be explained in depth later on. But
it is fairly easy to understand. It simply tells GTK that the button
is to be placed in the window where it will be displayed. Note that a
GTK container can only contain one widget. There are other widgets,
that are described later, which are designed to layout multiple
widgets in various ways.
This is a packing call, which will be explained in depth later on in
<ref id="sec_packing_widgets" name="Packing Widgets">. But it is
fairly easy to understand. It simply tells GTK that the button is to
be placed in the window where it will be displayed. Note that a GTK
container can only contain one widget. There are other widgets, that
are described later, which are designed to layout multiple widgets in
various ways.
<tscreen><verb>
gtk_container_add (GTK_CONTAINER (window), button);
......@@ -765,7 +768,7 @@ events come.
And the final return. Control returns here after gtk_quit() is called.
<tscreen><verb>
return 0;
return (0;
</verb></tscreen>
Now, when we click the mouse button on a GTK button, the widget emits
......@@ -779,17 +782,13 @@ as its argument, destroying the window widget. This causes the window
to emit the "destroy" signal, which is caught, and calls our destroy()
callback function, which simply exits GTK.
Another course of events, is to use the window manager to kill the
window. This will cause the "delete_event" to be emitted. This will
Another course of events is to use the window manager to kill the
window, which will cause the "delete_event" to be emitted. This will
call our "delete_event" handler. If we return TRUE here, the window
will be left as is and nothing will happen. Returning FALSE will cause
GTK to emit the "destroy" signal which of course, calls the "destroy"
GTK to emit the "destroy" signal which of course calls the "destroy"
callback, exiting GTK.
Note that these signals are not the same as the Unix system signals,
and are not implemented using them, although the terminology is almost
identical.
<!-- ***************************************************************** -->
<sect>Moving On
<!-- ***************************************************************** -->
......@@ -798,17 +797,18 @@ identical.
<sect1>Data Types
<p>
There are a few things you probably noticed in the previous examples
that need explaining. The gint, gchar etc. that you see are typedefs
to int and char respectively. This is done to get around that nasty
dependency on the size of simple data types when doing calculations.
that need explaining. The gint, gchar, etc. that you see are typedefs
to int and char, respectively, that are part of the GLlib system. This
is done to get around that nasty dependency on the size of simple data
types when doing calculations.
A good example is "gint32" which will be typedef'd to a 32 bit integer
for any given platform, whether it be the 64 bit alpha, or the 32 bit
i386. The typedefs are very straight forward and intuitive. They are
i386. The typedefs are very straightforward and intuitive. They are
all defined in glib/glib.h (which gets included from gtk.h).
You'll also notice the ability to use GtkWidget when the function
calls for a GtkObject. GTK is an object oriented design, and a widget
You'll also notice GTK's ability to use GtkWidget when the function
calls for an Object. GTK is an object oriented design, and a widget
is an object.
<!-- ----------------------------------------------------------------- -->
......@@ -892,7 +892,7 @@ int main( int argc,
/* Create a new window */
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
/* This is a new call, this just sets the title of our
/* This is a new call, which just sets the title of our
* new window to "Hello Buttons!" */
gtk_window_set_title (GTK_WINDOW (window), "Hello Buttons!");
......@@ -963,11 +963,12 @@ options to gtk_box_pack_start() while reading the next section. Try
resizing the window, and observe the behavior.
Just as a side note, there is another useful define for
gtk_window_new() - GTK_WINDOW_DIALOG. This interacts with the window
manager a little differently and should be used for transient windows.
gtk_window_new() - <tt/GTK_WINDOW_DIALOG/. This interacts with the
window manager a little differently and should be used for transient
windows.
<!-- ***************************************************************** -->
<sect>Packing Widgets
<sect>Packing Widgets <label id="sec_packing_widgets">
<!-- ***************************************************************** -->
<p>
When creating an application, you'll want to put more than one widget
......@@ -990,12 +991,12 @@ versa. You may use any combination of boxes inside or beside other
boxes to create the desired effect.
To create a new horizontal box, we use a call to gtk_hbox_new(), and
for vertical boxes, gtk_vbox_new().The gtk_box_pack_start() and
for vertical boxes, gtk_vbox_new(). The gtk_box_pack_start() and
gtk_box_pack_end() functions are used to place objects inside of these
containers. The gtk_box_pack_start() function will start at the top
and work its way down in a vbox, and pack left to right in an hbox.
gtk_box_pack_end() will do the opposite, packing from bottom to top in
a vbox, and right to left in an hbox. Using these functions allow us
a vbox, and right to left in an hbox. Using these functions allows us
to right justify or left justify our widgets and may be mixed in any
way to achieve the desired effect. We will use gtk_box_pack_start() in
most of our examples. An object may be another container or a
......@@ -1003,9 +1004,9 @@ widget. In fact, many widgets are actually containers themselves,
including the button, but we usually only use a label inside a button.
By using these calls, GTK knows where you want to place your widgets
so it can do automatic resizing and other nifty things. There's also a
number of options as to how your widgets should be packed. As you can
imagine, this method gives us a quite a bit of flexibility when
so it can do automatic resizing and other nifty things. There are also
a number of options as to how your widgets should be packed. As you
can imagine, this method gives us a quite a bit of flexibility when
placing and creating widgets.
<!-- ----------------------------------------------------------------- -->
......@@ -1013,7 +1014,7 @@ placing and creating widgets.
<p>
Because of this flexibility, packing boxes in GTK can be confusing at
first. There are a lot of options, and it's not immediately obvious how
they all fit together. In the end however, there are basically five
they all fit together. In the end, however, there are basically five
different styles.
<? <CENTER> >
......@@ -1026,7 +1027,7 @@ HEIGHT="235" ALT="Box Packing Example Image">
Each line contains one horizontal box (hbox) with several buttons. The
call to gtk_box_pack is shorthand for the call to pack each of the
buttons into the hbox. Each of the buttons is packed into the hbox the
same way (i.e. same arguments to the gtk_box_pack_start() function).
same way (i.e., same arguments to the gtk_box_pack_start() function).
This is the declaration of the gtk_box_pack_start function.
......@@ -1045,7 +1046,7 @@ we'll be packing buttons into boxes.
The expand argument to gtk_box_pack_start() and gtk_box_pack_end()
controls whether the widgets are laid out in the box to fill in all
the extra space in the box so the box is expanded to fill the area
alloted to it (TRUE). Or the box is shrunk to just fit the widgets
allotted to it (TRUE); or the box is shrunk to just fit the widgets
(FALSE). Setting expand to FALSE will allow you to do right and left
justification of your widgets. Otherwise, they will all expand to fit
into the box, and the same effect could be achieved by using only one
......@@ -1065,9 +1066,9 @@ GtkWidget *gtk_hbox_new (gint homogeneous,
The homogeneous argument to gtk_hbox_new (and the same for
gtk_vbox_new) controls whether each object in the box has the same
size (i.e. the same width in an hbox, or the same height in a
vbox). If it is set, the expand argument to the gtk_box_pack routines
is always turned on.
size (i.e., the same width in an hbox, or the same height in a
vbox). If it is set, the gtk_box_pack routines function essentially
as if the <tt/expand/ argument was always turned on.
What's the difference between spacing (set when the box is created)
and padding (set when elements are packed)? Spacing is added between
......@@ -1083,7 +1084,7 @@ ALT="Box Packing Example Image">
<? </CENTER> >
Here is the code used to create the above images. I've commented it
fairly heavily so hopefully you won't have any problems following
fairly heavily so I hope you won't have any problems following
it. Compile it yourself and play with it.
<!-- ----------------------------------------------------------------- -->
......@@ -1183,8 +1184,8 @@ int main( int argc,
/* Create our window */
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
/* You should always remember to connect the destroy signal to the
* main window. This is very important for proper intuitive
/* You should always remember to connect the delete_event signal
* to the main window. This is very important for proper intuitive
* behavior */
gtk_signal_connect (GTK_OBJECT (window), "delete_event",
GTK_SIGNAL_FUNC (delete_event), NULL);
......@@ -1234,8 +1235,8 @@ int main( int argc,
* but they are quite simple. */
separator = gtk_hseparator_new ();
/* Cack the separator into the vbox. Remember each of these
* widgets are being packed into a vbox, so they'll be stacked
/* Pack the separator into the vbox. Remember each of these
* widgets is being packed into a vbox, so they'll be stacked
* vertically. */
gtk_box_pack_start (GTK_BOX (box1), separator, FALSE, TRUE, 5);
gtk_widget_show (separator);
......@@ -1349,9 +1350,7 @@ int main( int argc,
/* Our quit button. */
button = gtk_button_new_with_label ("Quit");
/* Setup the signal to destroy the window. Remember that this will send
* the "destroy" signal to the window which will be caught by our signal
* handler as defined above. */
/* Setup the signal to terminate the program when the button is clicked */
gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (gtk_main_quit),
GTK_OBJECT (window));
......@@ -1394,7 +1393,7 @@ extremely useful in certain situations.
Using tables, we create a grid that we can place widgets in. The
widgets may take up as many spaces as we specify.
The first thing to look at of course, is the gtk_table_new function:
The first thing to look at, of course, is the gtk_table_new function:
<tscreen><verb>
GtkWidget *gtk_table_new( gint rows,
......@@ -1440,7 +1439,7 @@ void gtk_table_attach( GtkTable *table,
gint ypadding );
</verb></tscreen>
Where the first argument ("table") is the table you've created and the
The first argument ("table") is the table you've created and the
second ("child") the widget you wish to place in the table.
The left and right attach arguments specify where to place the widget,
......@@ -1458,18 +1457,18 @@ be bitwise OR'ed together to allow multiple options.
These options are:
<itemize>
<item>GTK_FILL - If the table box is larger than the widget, and
GTK_FILL is specified, the widget will expand to use all the room
<item><tt/GTK_FILL/ - If the table box is larger than the widget, and
<tt/GTK_FILL/ is specified, the widget will expand to use all the room
available.
<item>GTK_SHRINK - If the table widget was allocated less space then
was requested (usually by the user resizing the window), then the
<item><tt/GTK_SHRINK/ - If the table widget was allocated less space
then was requested (usually by the user resizing the window), then the
widgets would normally just be pushed off the bottom of the window and
disappear. If GTK_SHRINK is specified, the widgets will shrink with
the table.
disappear. If <tt/GTK_SHRINK/ is specified, the widgets will shrink
with the table.
<item>GTK_EXPAND - This will cause the table to expand to use up any
remaining space in the window.
<item><tt/GTK_EXPAND/ - This will cause the table to expand to use up
any remaining space in the window.
</itemize>
Padding is just like in boxes, creating a clear area around the widget
......@@ -1486,12 +1485,12 @@ void gtk_table_attach_defaults( GtkTable *table,
gint bottom_attach );
</verb></tscreen>
The X and Y options default to GTK_FILL | GTK_EXPAND, and X and Y
The X and Y options default to <tt/GTK_FILL | GTK_EXPAND/, and X and Y
padding are set to 0. The rest of the arguments are identical to the
previous function.
We also have gtk_table_set_row_spacing() and
gtk_table_set_col_spacing(). This places spacing between the rows at
gtk_table_set_col_spacing(). These places spacing between the rows at
the specified row or column.
<tscreen><verb>
......@@ -1678,27 +1677,27 @@ until the window itself is shown using the gtk_widget_show() function.
<!-- ----------------------------------------------------------------- -->
<sect1> Casting
<p>
You'll notice as you go on, that GTK uses a type casting system. This
You'll notice as you go on that GTK uses a type casting system. This
is always done using macros that both test the ability to cast the
given item, and perform the cast. Some common ones you will see are:
<itemize>
<item> GTK_WIDGET(widget)
<item> GTK_OBJECT(object)