Developing Linux Applications with GTK+ and GDK
Author: Eric Harlow
Publisher: New Riders
Price: $27.99 US
Reviewer: Michael J. Hammel
I've been working with GTK+ since its early introduction with the GIMP several years ago. I've watched it mature and become a fairly sophisticated widget set—one of the best I've seen for use under X. Until recently, GTK+ could be mastered only by those willing to dig into the source code, a feat not always for the faint of eyes and fingers.
Fortunately, the first of what I'm sure will be many texts on GTK+ has already hit the shelves. Eric Harlow's text Developing Linux Applications with GTK+ and GDK, published by New Riders, is an introduction to the world of GTK+ that many refugees from the world of MS Windows will find useful. Although not meant for the experienced user, this book does have its high points, even for the old hands of GTK+ like me.
The book is laid out in four sections:
Programming in GTK+
Drawing, Color and GDK
Chapter 1 isn't actually a chapter—it's the preface. The rest of the book starts with GTK+ basics and moves on to more complex issues with each section, which is made up of two to six chapters. The layout is a little strange with respect to example code. The chapters in the first section are introductory in nature, covering glib and some basic GTK+ features. The chapters in the second section each cover an example application, aimed at showing off what was learned in the first section. The third section, however, has its example code as the last two of its four chapters. The fourth section has the examples intermixed in each chapter. You might not really notice this layout pattern unless you step back and look at it from a reviewer's point of view, as I did, but it is a little strange to see the material broken down in that way. I would have expected examples simply to be intermixed with each chapter.
Chapter 2 describes glib, the library of utility routines for handling hashes, linked lists and memory management. I don't personally use glib all that much—I have simple library routines of my own to do these things I'd written long ago and carry from place to place. However, some widgets make use of certain glib features directly, so it helps to become familiar with what it is and what it does.
The next chapter shows how a simple GTK+ application is laid out. This leads into Chapter 4's introduction to basic widgets: buttons, labels, menus and text-entry widgets. Chapters 5 and 6 also describe widgets. Although several chapters are on widgets, you need to realize they can be fairly complex and offer many options and their accompanying support and convenience routines. No widget description takes up more than two pages (except the Clist and Text widgets, which are introduced very late in the book). Don't expect detailed API descriptions here—this text is very introductory in nature.
On pages 27 and 28, Eric did get one minor thing wrong—he said GTK+ came from the GIMP, and that it stands for the GNU Image Manipulation Project. The P in GIMP actually stands for “Program”. He also said GTK+ was born over licensing issues relating to the GIMP's original widget set, Motif (though not in so many words). I don't believe that was the driving reason. Motif was limited in some areas, and not having source made it difficult to extend it. Plus, I think the programmer wanted to work on a widget set from scratch anyway.
Eric describes accurately how to build applications using a single command line, including the recommended use of the gtk-config script. One additional item might be the use of the GTK_CONFIG environment variable. If you use this in your projects, you allow people who have multiple versions of GTK+ installed (it's a constantly evolving library) to build whichever version of the library they need.
The section on container widgets in Chapter 3 could have used some finer detail. Packing with boxes and tables is often a confusing area for recent converts.
Chapter 4 starts off with some discussion on the casting of widgets. GTK+ widgets are generic when created, so to use them with type-specific functions such as gtk_label_set_text, you need to cast the widget to the correct type. This is done with macros, such as GTK_LABEL. The discussion in the text is good but brief. A table showing inheritance for widgets would have been nice, but this isn't a reference text.
On page 51, Eric had a somewhat strange segue into the paragraph on signals after finishing off the discussion on casting. The information is useful, though it seemed to come in out of the blue.
The rest of Chapter 4 introduces the reader to labels, buttons, text input (known as entry widgets), simple lists, combo boxes (lists with text input fields), option menus and generic containers (widgets that hold other widgets). This is where some discussion on naming schemes for widget-specific functions would probably have been helpful for those willing to rummage through the GTK+ source code.
Chapters 4, 5 and 6 are descriptions of various widgets. Chapter 7 begins the second section and its example applications. The use of the notepad application as an example was a good idea—it's a familiar application to developers—but the section on the text widget should be tempered with the knowledge that it's likely to change in the next major release of GTK+. Owen Taylor, the man who wrote the original text widget, has said the design doesn't lend itself well to new features, and he has some better ideas on how to redesign it. Whether that will mean applications using the widget will no longer work is unknown. These changes will probably not happen for some time, however.
One problem with printed texts is the amount of time it takes publishers to get them to market and onto shelves. Because of this, the text is a little behind the curve for the current version of GTK+, which is version 1.2. I believe Eric was working with version 1.1.5 at the time he wrote the text. Some of the examples, although they work, use outdated functions. For example, he uses gtk_label_set in many places in the code. The correct function to use with GTK 1.2 is gtk_label_set_text. You can check the GTK+ web site (http://www.gtk.org/) to find changes from GTK 1.0 to 1.2, if you are uncertain about any of the other code in the book.
One common concern about labels, not mentioned until the last chapter on creating your own widgets, is that labels are subclassed from the GtkMisc widget, which means labels don't receive signals. Thus, they must be wrapped in other widgets. For event handling, you would drop the label inside a GtkEventBox widget. Remember this bit of information—you're bound to need it eventually.
Chapters 10 through 13 make up the third section, covering issues relating to color and drawing with low-level GDK routines. I found chapter 10 to be the most useful, as I finally figured out how to do double buffering. Double buffering is simply a matter of drawing in an off-screen (non-visible) region—a pixmap—and then copying that region over the currently visible version. The technique is simple once you learn it. It's a subtle piece of code, and often hidden in the bowels of more expansive subroutines. Eric explains double buffering clearly and provides good examples of how to use it.
Chapter 11 moves into styles, colors and fonts. The discussion here is like the rest of the text: brief but accurate. The styles section, however, talks about the use of styles programmatically. It doesn't discuss them from the point of view of gtkrc files. Styles are, specifically, an API term for GTK+, but adding themes (what an end user might refer to as a style) is a big deal with applications using GTK+. The gtkrc files add a “look”, but are far less sophisticated than the application-default files common with Motif. The latter allow external definition of command-line arguments, for example. Currently, gtkrc strictly handles look-and-feel issues.
There is no discussion on the use of command-line arguments with GTK+. Motif programmers are probably used to Motif's built-in command-line parser. GTK+ doesn't have such a thing. If you plan on having command-line arguments, you will probably want to use getopt_long, unless you're worried about portability to non-Linux platforms. In that case, you may have to roll your own parser, since not all UNIX boxes have getopt_long.
Source code for the book is available from New Riders' web site. It comes in gzipped tar format, with the examples broken out into chapter-by-chapter directories. There is no top-level Makefile, but the individual directories build easily enough. Be sure to have the gtk-config script in your path. Most of the applications worked fine for me. The molecule example didn't seem to draw any molecules, unfortunately. And the double buffering example—one clock without and one clock with—didn't show the advantage of double buffering on my system, because it's fast enough (400MHz) that the redraws in the unbuffered version were hardly noticeable. But you should pay attention to that example. Double buffering is a good thing to learn if you're doing any serious amount of drawing with GDK.
Considering the introductory nature of this book, I wonder how useful the last chapter on writing your own widgets will be to others. This space might have been better used to cover more details on widget specifics.
Eric's writing style is succinct and clear. The book has few typos—on-line documentation is notorious for poor editing, which is one reason why printed, professional documentation is here to stay. Reading this book is certainly easier than reading many of the on-line documents I've seen.
This book is a beginner's guide to writing GTK+ applications. It is not a reference, and leaves much to be desired regarding in-depth widget explanations. If you need only an introduction and you're looking to migrate to Linux and GTK+, it isn't a bad place to start.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide