GTK v1.2 Tutorial(英文)

gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
 GTK_SIGNAL_FUNC (gtk_widget_destroy),
 GTK_OBJECT (window));

　　This is a packing call, which will be explained in depth later on in 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.

gtk_container_add (GTK_CONTAINER (window), button);

　　Now we have everything set up the way we want it to be. With all the signal handlers in place, and the button placed in the window where it should be, we ask GTK to "show" the widgets on the screen. The window widget is shown last so the whole window will pop up at once rather than seeing the window pop up, and then the button form inside of it. Although with such a simple example, you'd never notice.

gtk_widget_show (button);
gtk_widget_show (window);

　　And of course, we call gtk_main() which waits for events to come from the X server and will call on the widgets to emit signals when these events come.

gtk_main ();

　　And the final return. Control returns here after gtk_quit() is called.

return (0);

　　Now, when we click the mouse button on a GTK button, the widget emits a "clicked" signal. In order for us to use this information, our program sets up a signal handler to catch that signal, which dispatches the function of our choice. In our example, when the button we created is "clicked", the hello() function is called with a NULL argument, and then the next handler for this signal is called. This calls the gtk_widget_destroy() function, passing it the window widget 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, 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" callback, exiting GTK.

3. Moving On

3.1 Data Types

　　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, 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 straightforward and intuitive. They are all defined in glib/glib.h (which gets included from gtk.h).

　　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.

3.2 More on Signal Handlers

　　Lets take another look at the gtk_signal_connect declaration.

gint gtk_signal_connect( GtkObject *object,
 gchar *name,
 GtkSignalFunc func,
 gpointer func_data );

　　Notice the gint return value? This is a tag that identifies your callback function. As stated above, you may have as many callbacks per signal and per object as you need, and each will be executed in turn, in the order they were attached.

　　This tag allows you to remove this callback from the list by using:

void gtk_signal_disconnect( GtkObject *object,gint id );

　　So, by passing in the widget you wish to remove the handler from, and the tag returned by one of the signal_connect functions, you can disconnect a signal handler.

　　You can also temporarily disable signal handlers with the gtk_signal_handler_block() and gtk_signal_handler_unblock() family of functions.