gtk-gnome-intro.html
来自「linux下gnome编程」· HTML 代码 · 共 999 行 · 第 1/3 页
HTML
999 行
<HTML><HEAD><TITLE>The GTK+/GNOME System</TITLE><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.61"><LINKREL="HOME"TITLE="Writing GNOME Applications"HREF="index.html"><LINKREL="PREVIOUS"TITLE="Acknowledgments"HREF="acknowledgements.html"><LINKREL="NEXT"TITLE="GDK"HREF="gdk.html"></HEAD><BODYCLASS="CHAPTER"><DIVCLASS="NAVHEADER"><TABLEWIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">Writing GNOME Applications</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="acknowledgements.html">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="gdk.html">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="CHAPTER"><H1><ANAME="GTK-GNOME-INTRO">Chapter 2. The GTK+/GNOME System</A></H1><DIVCLASS="TOC"><DL><DT><B>Table of Contents</B></DT><DT><AHREF="gtk-gnome-intro.html#GLIB">GLib</A></DT><DT><AHREF="gdk.html">GDK</A></DT><DT><AHREF="gtk.html">GTK+</A></DT><DT><AHREF="gnome-intro.html">GNOME</A></DT></DL></DIV><P> Although it's possible to write an application using only raw Xlib calls and ANSI C functions, it's not something you would normally want to do unless you had no other choice. For each application, you'll end up implementing your own event-polling loop, your own data structures, and very likely your own widget system-all from scratch. Other widget toolkits exist, like Motif and Xt, but they may not be what you're looking for either. </P><P> When the original GIMP developers began their project, they looked at the current toolkits and decided that it was better to start from scratch. In a decision that would eventually affect thousands of free-software developers, they chose to extract all the widget-related code from the GIMP and put it into a standalone set of libraries called GTK.1 Later the GNOME team added other layers and libraries, which we'll introduce in this chapter and explore throughout the rest of the book. </P><P> Unfortunately, a detailed description of GTK+ is beyond the scope of this book. You can read the online documentation at http://www.gtk.org/rdp; you can also learn a lot from looking at the source code for existing GNOME and GTK+ applications. </P><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="GLIB">GLib</A></H1><P> GLib is a tight little library, full of generic data-handling functions; it also provides other abstractions to make porting and cross-platform development easier, such as generic data types, thread support, dynamic library loading, and even a lexical scanner. GLib forms the solid, portable base upon which GTK+, ORBit, and GNOME rest. </P><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN50">Simple Data Types</A></H2><P> Data is the currency of all applications. All variables you use must have an explicit data type (at least in strictly typed languages like C and C++; not all languages are so strict about it). The C language comes with a comprehensive set of these data types, including int, char, long, and double, among others. C's data types can express just about any fundamental flavor of data you'll come across, but they don't protect us from all the dangers that might arise. C is deliberately vague on the sizes of certain data types, particularly the int type. The bit size of the int type might be different on different platforms. Simply recompiling the same code on a different platform can change the behavior of your program in subtle ways. On a 64-bit platform, 3 billion might be a valid value for your int; on a 32-bit platform, however, 3 billion might overflow the bounds of the data type, leaving you with a bogus value. </P><P> GLib defines a complete set of data types that you can use in your applications to make it easier to port to different platforms. When you use these data types, you insulate your applications from the details of each new architecture. You no longer have to worry about whether an integer type is 32 bits or 64 bits, or what native type to use for your Boolean variables. When GLib is installed on a new system, it uses the autoconf system to probe for the exact sizes of the various data types and makes the proper typedef assignments for you. </P><P> If you want exactly a 16-bit unsigned integer, GLib has a data type for that, guint16. If instead you need a 64-bit signed integer, GLib has the data type gint64 for you. Rather than leaving it up to you to guess how many bits an integer holds, GLib announces it right in the data type. Other data types are gint, guint32, gboolean, glong, gdouble, and so on. Most of them are typedef instances of standard C types. See the GLib documentation for a more complete listing of GLib's types. </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN55">Namespaces</A></H2><P> GLib, GTK+, and GNOME all use a simple, consistent function-naming convention of the form namespace_object_operation( ). Thus all functions are named from left to right, according to scope. All GLib functions are prefixed with a namespace of "g," all GTK+ functions are prefixed with "gtk," and all GNOME functions use the "gnome" namespace. </P><P> The second part of the function name is always the object name, which usually indicates which data structure the function will operate on. For example, all gtk_widget_* functions operate on a GtkWidget structure supplied as the first parameter to the function. </P><P> The function name ends with the operation to perform. Depending on the particular operation, the function may or may not have additional parameters beyond the first object parameter. Here are a couple examples that operate on the GtkWidget structure: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">void gtk_widget_show(GtkWidget *widget);void gtk_widget_set_sensitive(GtkWidget *widget, gboolean sensitive); </PRE></TD></TR></TABLE></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN61">Logging</A></H2><P> When things go wrong in your application, it's nice to have a way to communicate with your users about the problem. Some of this communication will take the form of graphical dialog boxes (see Chapter 7). These pop-up windows are good for warnings, error messages, and spontaneous data gathering, but by their nature they don't leave a trace of their passing. If something goes horribly awry and the only response is an error dialog, the user will have to quickly grab a piece of paper and write down the error before closing the window. Sometimes you just want to output text messages to stdout (the text console), or permanently to a log file. GLib has a nice, configurable set of logging func- tions that allow you to do this in a flexible, portable way. </P><P> Traditionally, C applications use some form of the printf( ) function to write messages to the console. Alternatively, variations of write( ) and fprintf( ) can send the same messages to a file. If you wanted to reroute your logging messages between these two output styles at runtime, you would have to write a wrapper logging function to handle the logic, and call the wrapper instead of calling printf( ) and write( ) directly. This is exactly what GLib does. </P><P> The four main logging functions are, in increasing order of severity, </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">void g_print(const gchar *format, ...);void g_message(const gchar *format, ...);void g_warning(const gchar *format, ...);void g_error(const gchar *format, ...); </PRE></TD></TR></TABLE><P> They behave just like a normal printf( ) statement: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR><TD><PRECLASS="PROGRAMLISTING">g_message("%d bottles of beer left in the fridge", num_bottles); </PRE></TD></TR></TABLE><P> Notice that for g_message( ), g_warning( ), and g_error( ), you don't need to worry about line breaks. If you include the character "\n" at the end of your format strings, you'll end up with double spacing between log messages. </P><P> Each of these four logging channels handles its formatted messages in its own particular way. By default, all four channels write to the stdout of the console the application was run from. The g_print( ) function passes the text on without changing it; the other three add a little extra formatting to indicate the severity of the message to the user. In addition to printing a logging message, the g_error( ( )) function calls abort( ), which brings your program to a screeching halt. </P><P> It's also possible to intercept these logging messages and handle them in a custom manner, most likely sending them to a file rather than to stdout. You can override each logging channel separately-for example, if you want to send the output of only g_message( ) to a file, leaving the other channels alone. The handler function prototype and the GLib function you call to set it up look like this: </P><TABLEBORDER="0"BGCOLOR="#E0E0E0"WIDTH="100%"><TR⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?