Being unique is usually a good thing, but not in the case of libraries. With software, wider popularity means more reviews, more bugs reported (and, therefore, fixed), and a better chance that different cases and unusual circumstances are tested. All this generally leads to better and easier-to-use libraries. Fortunately, GTK+ is a big player here and one of the more widely used software packages. Note the following information about the different platforms on which GTK+ operates:

UNIX®

UNIX is the original platform on which GTK+ was written, and GTK+ (together with rival Qt tool kit) is a de-facto UNIX standard. Literally thousands of GTK+ applications have been written and are running on UNIX (and UNIX-like) systems. Besides stand-alone applications, GTK+ also hosts two major desktop environments (GNOME, and XFce), aimed at providing a complete user experience. This richness makes for self-sustaining ecosystems, in which every development spurs projects based on newly gained capabilities. Many artifacts of this development later get folded into GTK+ itself -- for example, large parts of libgnomeui can now be found inside GTK+ proper.

Microsoft® Windows®

The Win32 port was later added to the set of platforms on which GTK+ runs, but now Win32 is a first-class citizen on its own. Most small and medium GTK+ applications compile and run on Win32 right away (provided they don't do anything fundamentally UNIX-specific, of course), and bigger applications can be ported successfully. The original GNU Image Manipulation Program (GIMP) is the best (and chronologically first) example here, but not the only one. For example, the excellent Gnumeric spreadsheet has sported an official Windows port since V1.4.

Mac OS X

Apple's latest operating system is basically a UNIX under the hood, so getting GTK+ applications to work on Macs isn't hard. In fact, some applications, such as the GIMP, have been specially modified to better fit into Mac OS X's unique user interface (UI) conventions.

The application production line

Like it or not, software development consists of much more than just happily writing lines of code. To create a successful product, you first need to create a production line that allows your developers to work.

The programmer

The most crucial part of this production line is, of course, the programmer. If a library is difficult to use, has strange requirements, or is difficult to marry with other components, it won't make a good basis for your product. Luckily, GTK+ has none of these problems. The application program interface (API) is consistent (if you don't count an occasional compromise for the sake of backward-compatibility), and designed to be easy to use and remember. Proper care is taken to avoid clashing with other libraries: Everything is properly name-spaced (using mechanisms available for your given programming language), and the number of symbols exported is kept to minimum to make the library safer and faster when linking.

The build system

Because compiling is something you'll do thousands of times during development, you naturally want to use an automated build system to free you from doing it by hand. And because that build system has to address all your software building, you need to ensure that the parts play nicely together. Here, GTK+ truly excels. It has literally a single integration point: the pkg-config command. This command allows you to check whether GTK+ is present and in the proper version and to split all those insanely long and boring lines of options so compilers can find their libraries.

GTK+ also doesn't have any special requirements, and all you really need to use it is to include one header file. No preprocessors or special compilers are involved, nor is anything else that could have surprising effects.

GTK+ itself uses GNU Autotools, and it includes ready-made macros for Autoconf and Automake (written for the GNOME project) that make it possible to detect and appropriately configure GTK+ with a single call. But even if you use a different build system, you can easily integrate GTK+ with it. You just need a well-defined call to pkg-config. Or, if you're using a system based on directories (such as Microsoft Visual Studio), simply include several directories in your build path.

Delivering your finished application

Delivering final products to users is highly platform-specific, so how you integrate your application with GTK+ varies among platforms. For UNIX platforms -- and especially Linux® -- GTK+ can be considered a system library distributed by an operating system vendor. If you don't want that, the Autopackage project (see Resources) is one solution that allows you to create packages that will automatically install needed libraries.

On Windows, many installer systems exist. For example, the standard Windows InstallShield and Nullsoft's NSIS are widely used to provide a variety of software, including GTK+ itself. All binary distributions of the library use standard registry keys and configuration data, making it possible for multiple applications to use the same shared copy and also allowing you to reliably package your application should you choose to use some other installer system.

Cross-platform availability

Depending on your target system, the availability (and, thus, the expectations about deployment) vary:

• For a Linux distribution, you can reasonably assume that GTK+ will be available using usual distribution means. Most distributions are quick to incorporate GTK+ releases, and you can count on at least the two most recent versions being available in the latest release of the given distribution. However, because it's not guaranteed that all your users will be up to date with their Linux versions, target the oldest possible version of Linux with which your application can work.
• On computers running Windows, GTK+ is strictly a third-party component. However, thanks to the unified layout of different installer packages, you can safely rely on an existing GTK+ installation if one is found and install your own otherwise. Because installation of the GTK+ runtime is included in your installation process, you can more freely choose the versions you target, but stick with older versions, if possible. The GTK+ team pays great attention to keeping GTK+ backward-compatible, but it is simply impossible to catch all bugs. As usual, working with older versions of the library has the greatest chance of making applications easily installable.
• For Mac OS X, GTK+ is also a completely foreign package. To be safe, provide a self-contained application bundle to save your users from dependency hurdles. For an example of such a bundle, take a look at how Gimp.app is built (see Resources).

You should note that GTK+ on Mac OS X comes in two flavors. For all versions released to date, you have to use GTK+ through Apple's X11-to-OS X bridge. However, in the latest development version, a new native port to the Mac OS X windowing system was added, making it possible in the future to give that port a level of integration similar to what the Win32 port has today.

You also need to know exactly what application binary interface (ABI)-compatibility means in GTK+. Library developers are committed to keeping GTK+ backward-compatible, but for your application, that only means that the application will remain forward-compatible -- that is, working across GTK+ upgrades. In particular, even if your source code uses only 2.2 APIs, but you compile with V2.6, the resulting binary will not run with GTK+ V2.2. This is because any ABI additions from later versions will be referenced during compile time, generating runtime errors on systems with an earlier version installed.

The way to get a binary compatible with, say, 2.2 onward is to install a real GTK+ V2.2 distribution and compile your package against those headers. While arguably this is not the easiest way for the developer, it's the only reliable way.

Alternative approaches to this problem exist, such as explicit version parameters you can define during compilation to switch between header versions. This technique is used in the Windows software development kit (SDK), for example. But this method also has drawbacks, causing the resulting headers to be much harder to understand and maintain and sometimes creating surprising effects. For this reason, GTK+ maintainers decided not to support this method of compilation.

If you're using the Linux platform, you can get old GTK+ headers in a conveniently pre-packaged form from the Autopackage project together with other tools that simplify the generation of widely distributable binaries. See Resources for more information.

Back to top

Customizing GTK+ to your needs

Often, you won't be satisfied with the capabilities that GTK+ provides by default. The reasons for this may be two-fold: Either you want additional functionality that isn't present in the base library, or you want to influence some aspects of the library's functioning to better fit your needs.

The first case is straightforward. You need to find an external library offering the desired functions. There are several places to begin looking for a provider. Very often, a need similar to yours has already arisen in one of the big projects like GNOME. For this reason, GNOME keeps several modules that serve as a kind of sandbox in which features live before they mature enough to be integrated into GTK+ but are useful and working nevertheless. The most prominent module of this kind in the GNOME CVS is the so-called libegg. You can also look on many sites that provide hosting, such as SourceForge.net and freshmeat (see Resources).

The other reason occurs when you want to modify some aspects of GTK+ itself. For example, you may need to run GTK+ on some embedded architecture or add support for some special interaction type. Depending on your needs (and capabilities), several approaches are available.

In the simplest case, you can just sign on to a mailing list and ask whether someone has done what you're looking to do before. If your changes are of general interest and sufficient quality, there's a good chance they'll be integrated into the GTK+ main distribution.

However, if your project is particularly involved, you might consider hiring a specialized consulting company that can help you communicate with the community and identify crucial points. This was the approach taken recently by Nokia, which decided to use GTK+ as a basis for its new line of personal phone appliances. The result was the maemo platform, which is enjoying particularly good reception in the community (no pun intended). Careful choice of partners and methods can lead to the creation of something that benefits both sides; The company gets many experienced developers eager to try a new toy, while the community gets back many improvements made during the development and a completely new use case, which will widen the array of possibilities GTK+ has to offer.

Back to top

The GTK+ community

At all times during your adventure with GTK+, the community gathering around it will be your first line of support. Therefore, it is crucial that you know the right starting points. Such knowledge will save you a lot of time and potential misunderstandings.

GTK+-related development gathers primarily around three mailing lists:

gtk-list

This general list answers all kinds of GTK+ questions not necessarily related to programming. For example, here you can ask questions regarding licensing. It is also the only list where it's acceptable to post job offers.

gtk-app-devel-list

This list concentrates on the actual development of GTK+ applications. It should also be your default choice for all kinds of programming questions. If you don't know where to ask, ask here.

gtk-devel-list

This list is dedicated to developers working on GTK+ itself (as opposed to applications). Because effective communication is crucial to the smooth development of future versions, it's important to keep unrelated questions off the list. For example, asking a question about using GtkTreeView is not considered appropriate. However, a question about something you believe to be a bug or possibly a valuable enhancement is definitely valid -- indeed, it's very welcome.

GTK+ developers regularly read all three lists, so you don't have to fear that your post will be overlooked.

Another site you should be familiar with is Bugzilla, a GNOME bug-tracking system that also hosts GTK+'s bug database. Whenever you're in doubt about some incorrect behavior, consult Bugzilla to see if it has been reported already. You can also report issues yourself to help make GTK+ even better. Don't be afraid to file something you're not sure about, as long as you provide sufficient details. The worst that can happen is your bug being closed with a NOTABUG resolution.

Aside from these sources, you can also get real-time support on many Internet Relay Chat (IRC) channels. The primary server is GIMP.net. On channels #gtk+ and #gnome, someone is usually available to help you. But be patient: "Usually" does not necessarily mean "within 5 minutes."

When you get in touch with the community, you'll discover that there are many great people there, and it can be fun just to hang around, perhaps helping someone else with issues you're familiar with. Just remember that you won't always be heard the first time around, and everything should be well.

Back to top

A look into the future

GTK+ is continuously striving to improve its usefulness for developers, and each new version delivers additional features designed to make their lives easier. For that reason, GTK+ also implements several interoperability standards, like those defined by the freedesktop project (see Resources).

However, one especially prominent project is designed to aid Independent Software Vendors (ISVs) and make the process of finding the right tools more straightforward. This effort is dubbed Project Ridley, and it consists of the integration of many previously independent libraries and add-ons into a single easy-to-use, coherent platform. For example, many of the current GNOME libraries will be integrated to bring their benefits to all platforms on which GTK+ runs. Among others, the libglade you encountered in Part 2 of this series is scheduled for inclusion in the GTK+ platform. It is expected that after Project Ridley is complete, the resulting platform will be numbered GTK+ V3.0 (but will remain compatible with current 2.x releases).

Back to top

Conclusion

In this last article of the "GTK+ fundamentals" series, you have seen many aspects of creating successful software products. You have seen how GTK+ is supported on different platforms, how best to deliver your GTK+ applications, and ways in which you can customize GTK+ to better fit your needs. Finally, you got a sneak preview of future editions and have been equipped with the knowledge of where to start your big adventure with GTK+.

I hope that we will be able to meet soon -- on one of the mailing lists or perhaps on an IRC channel. In either case, I look forward to further introducing you into the wonderful world of GTK+.

Resources

Learn

• Find all of the articles in the developerWorks "GTK+ fundamentals" series.
  
  
• GTK.org is the home of the GTK+ project.
  
  
• GNOME Bugzilla is the bug-tracking system for GNOME and GTK+.
  
  
• freedesktop is the interoperability project dedicated to open source desktops.
  
  
• ProjectRidley is dedicated to bringing GTK+ to new level as a programming platform.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  

Get products and technologies

• Discover autopackage, a cross-distribution packaging solution for Linux.
  
  
• Download Gimp.app, a sample application bundle for Mac OS X using GTK+.
  
  
• SourceForge is a free hosting farm and home to many GTK+ applications and libraries.
  
  
• Check out freshmeat, which is a repository of various projects, many of which are GTK+-related.
  
  
• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Check out gtk-list, a general discussion list for GTK+.
  
  
• Also check out gtk-app-devel-list, the main programming forum for GTK+ applications.
  
  
• The gtk-devel-list discussion list is dedicated to the development of GTK+ itself.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the author

Maciej Katafiasz is a graduate student in computer science and has been using open source technologies since high school. A user of the GNOME desktop since its 1.0 days, after version 2.0 was released, he fell in love with it and learned GTK+ to be able to develop for his favorite desktop.

Rate this article

Comments

Back to top

Table of contents

• The application production line
• Customizing GTK+ to your needs
• The GTK+ community
• A look into the future
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Open source on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers