GTK+ Foundation Classes

FAQ

Home

News

History

FAQ

Documentation

Download

Contact

Links

What is GTK+?

GTK+ is a powerful multi-platform toolkit for creating graphical user interfaces. Written completely in C, it comprises a collection of graphical objects called widgets. There are common widgets, such as buttons, menus, dialogs and complex widgets, such as file chooser and color selection widgets. GTK+ is used by a large number of applications and is the toolkit used by the GNOME desktop environment. GTK+ is free software and part of the GNU Project. The licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties.

What is GFC?

GFC is the GTK+ Foundation Classes, a C++ language binding for GTK+. GFC combines the power of GTK+ and the power of C++ into a state-of-the-art graphical user interface toolkit that makes developing GTK+ applications easy, intuitive and efficient. GFC uses such C++ language features as improved type checking, data abstraction, encapsulation, inheritance and polymorphism to make it easy for programmers to develop and reuse GFC source code.

There are several other C++ language bindings for GTK+, but compared to these GFC has a more compact API that is optimized for size, execution speed and performance. There are other language bindings for GTK+, including C#, Java, Objective-C, Guile, Perl and PyGtk. You can find out more information on these, and others, in the bindings page on the GTK+ web site.

What are the goals of the GFC project?

The main goal for the GFC project is to implement a compact, fast and easy to use C++ application development platform for GTK+, without compromising on any essential C++ features. It's important that the GFC API be kept compact and is easily understood, so that GTK+ programmers can continue use all the concepts they're already familiar with.

Some other goals for the GFC project are:

Stable interfaces, with an easy upgrade path between releases.
Judicious use of the standard C++ library features.
Automatic memory management to help prevent memory leaks.
Consistency; to make GFC easier to learn, the interfaces religiously follow strict conventions.
Ease of use; GFC gives you a integrated package, with all the interfaces you need.
Documentation; stable releases of GFC will have excellent documentation.
Maturity; GFC will not be maintained as a "bleeding edge" library; it will support features as they become mature.

What is the relationship between GFC and GTK+?

GTK+ is a C toolkit that comprises several component libraries. These include:

the ATK Accessibility Toolkit
the GDK Drawing Kit
the GDK-PIXBUF Image Library
the GLib utility library
the GTK GUI Toolkit
the Pango internationalized text handling library

GFC wraps these C libraries in a consistent and easy to use C++ interface. GFC should be immediately familiar to you because it uses the same widget hierarchy, and the same API names and identifiers as GTK+.

Why use GFC instead of plain GTK+?

GFC combines the power of GTK+ and the power of C++ into a state-of-the-art application development platform that makes GTK+ programming easier and more intuitive. Over the years application programming has become complex. Today C++ is a better way to manage that complexity because it provides you with a variety of designs, both object-oriented and conventional, that let you develop high-quality applications. Properly used, C++ code is easily maintainable, is extensible and can be performance and memory efficient.

What does the GFC development platform include?

GFC includes C++ wrappers for most of the features implemented in the GTK+ package. These include:

A GUI widget toolkit.
An Accessibility Toolkit for writing programs for the disabled.
Internationalized text handling.
Main loop support.
A new virtual signal system optimized for size, execution speed and performance.
A standard string compatible UTF-8 string class.
A widget demonstration program.
Example and test applications
Full documentation.

GFC has two main modules, GFC-Core and GFC-UI. GFC-Core is the core object library; it wraps the GLib object system and selected objects from the GLIb utility library. GFC-UI is the user interface library; it wraps most of the objects found in the ATK, GDK, GDK-PIXBUF, GTK and Pango libraries. There are also add-on libraries such as GFC-GConf, a GFC binding for the GNOME Configuration System that provides easy access to the GConf database.

How does GFC improve on plain GTK+?

GFC adds a number of essential C++ features:

Namespace support
Type safety, no need for type casting.
Use of C++ native types such as string and vector.
Automatic memory management.
Derivation of new widgets using standard C++ mechanisms.
Deprecated and legacy interfaces that have built up over the years in GTK+ are not included in GFC.
A Typesafe C++ system of signals and slots based on the new libsigc++ 2.0 library.
Full wrapper for all C types, including enumerations and GDK types.

Who is behind GFC?

GFC is being developed by The GFC Development Team. Currently the primary maintainer is Jeff Franks.

How is GFC licensed?

GFC is licensed under the GNU Library or Lesser General Public License (LGPL), similar to most libraries on the Linux operating system. In general terms, this means that it's OK to develop proprietary software with GFC; however you should read the license yourself (or have your lawyers read it), in order to get all the details about your rights and responsibilities.

Why write yet another C++ language binding for GTK+?

I began writing GFC about four years ago, at a time when I was new to Linux and needed to learn GTK+ programming. I did look around for a usable C++ language binding but couldn't find one that I liked. There were several available, including Gtkmm, QT, V, VDK and wxWindows but I found problems with these. Forced to give up, I bought a good GTK+ programming book and set about learning GTK+ C programming. As I worked my way through the examples in the book, as an exercise, I ported them to C++. Before too long I had written an small C++ interface for GTK+ that worked. When GTK+ development version 1.3.1 was released I decided to try and develop this small interface into a serious C++ language binding for GTK+-2.0. The original binding was called GCode. I worked on it in my spare time and as soon as I had a workable framework in place I uploaded its source code base to SourceForge and began public development, on May 30th, 2002. Unfortunately there was a CAD program also called GCode, so I was forced to find a new name.

The project was renamed Inti: Integrated Foundation Classes, after the abandoned project of the same name on which GCode was based. Inti released versions up to 1.2.0. During development of the next version, Inti 2.0, it became obvious that the project name Inti had no real significance and so it was changed to GTK+ Foundation Classes, a name that better reflected the usage of the library. There was no Inti 2.0 release. The Inti 2.0 source code base was renamed and released as GFC 2.0.

How does GFC differ from the other C++ language bindings for GTK+?

The are several differences:

GFC has a new virtual signal handler system which is optimized for size, execution speed and performance.
GFC is judicious in its use of C++ language features, which also improves performance.
GFC uses only one exception and that's in its implementation of operator new. This leaves the decision whether or not to use exceptions optional and up to the programmer.
GFC does not implement STL-like widget interfaces. Instead of adding extra layers of C++ object code and risking a bloated interface, GFC just wraps the GTK+ API. Extra code is only added when it's essential to the structure or function of the GFC libraries.
GFC uses the new libsigc2 callback library to implement a typesafe system of C++ signals and slots that is an alternative to the new virtual signal handler system mentioned above.
GFC uses automatic C++ memory management based on the GTK+ reference counting system.

Why should I program GTK+ in C++?

GTK+ is an object-oriented application framework but C is not an object-oriented programming language. GTK+ makes a good job at implementing its object-oriented style but it requires a lot of casting, which can get cumbersome. In comparison, object-oriented programming comes naturally to C++ but it doesn't stop there. The C++ programming language provides alternative programming styles including straight C-style, abstract classes, concrete classes, traditional class hierarchies, abstract class hierarchies and generic programming. An experienced C++ programmer will use several of these programming styles in one application.

You hear a lot of criticism of C++, most of it unfounded, and usually from bad programmers who fail to understand and respect the C++ language's strengths and limitations. Yes, there is a lot of stuff to learn in C++, but if you take the time you will discover the raw programming power that sets C++ apart.

How does the new GFC virtual signal system work?

Most C++ bindings put the widget virtual signal handlers, all 70+ of them, into the widget classes. This hooks a virtual signal handler directly into the GTK+ signal emission chain. Then, for every GTK+ widget signal emitted a corresponding virtual signal handler gets called, which usually does nothing but call the default GTK+ signal handler. What a waste! Then there is the huge virtual function table that each widget inherits, filled with 70+ entries, and the overhead needed to call them. And that's just for one widget. Multiply that by all the widgets in your application and it starts to add up.

The pre-eminent goal for GFC 2.0 was to implement a virtual signal handler system that overcame these problems. It took some time to develop but the end result is impressive. Now there is a real potential for smaller, faster applications, depending on your C++ programming style. So how does the new system work? In GFC 2.0 all widget virtual signal handlers have been moved into an abstract signal class hierarchy. To override one or more widget virtual signal handlers a custom widget class must multiplely inherit from the parent widget's signal class, or one of its base signal classes. For example, to customize your main window by overriding one or more Gtk::Widget signal handlers you would derive your window class like this:

#include <gfc/gtk/window.hh>

                        #include
                        <gfc/gtk/widgetsignals.hh>

class MyWindow : public Gtk::Window, public Gtk::WidgetSignals

{

                        protected:

    virtual bool
on_delete_event(const
Gdk::EventAny& event);

   
                        virtual
bool on_configure_event(const
Gdk::EventConfigure& event);

                           
                        virtual
bool on_expose_event(const
Gdk::EventExpose& event);

                        

                        public:

    MyWindow();

    virtual
~MyWindow();

};

                        

MyWindow::MyWindow()

: Gtk::WidgetSignals(this)

{

}

The on_delete_event(), on_configure_event() and on_expose_event() signal handlers are all inherited from Gtk::WidgetSignals. One thing to note is that the widget header file must be included before the widget signal header file. This is because the signal class header files are interfaces and don't include widget header files. The other thing to note is that the Gtk::WidgetSignals constructor takes a widget pointer as its only argument. This enforces type safety and simplifies the inheritance hierarchy.

How does GFC memory management work?

GFC uses GTK+ reference counting to manage the memory of its objects. This ensures that the principles of memory management are consistent across the GTK+ and GFC libraries, and it minimizes the risks of memory leaks. Essentially, if you already know how to manage memory in GTK+ using functions like g_object_ref() and g_object_unref() then you already know how to manage memory in GFC with the corresponding functions ref() and unref().

Most GFC objects can either be created dynamically on the heap or automatically on the stack. When you create a GFC object dynamically, by calling operator new, the caller is responsible for correctly handling the new object's reference count. Objects that derive directly from G::Object, but not Gtk::Object, are created with an initial reference count of one. This reference count is owned by the caller and must be explicitly cleared by calling unref(). Objects that derive from Gtk::Object are also created with an initial reference count of one, but unlike G::Objects the initial reference count is floating. A floating reference count is not owned by any object. Its purpose is the keep the new Gtk::Object alive until an owner calls ref() on the object for the first time. The first call to ref() will automatically sink a floating object so there is no sink() function. Once a new Gtk::Object has been referenced it is no longer floating but its reference count will still be one. At this point the caller owns the new Gtk::Object and is responsible for clearing its initial reference count by calling unref().

One thing to note about Gtk::Objects. You can pass a newly created Gtk::Object as an argument to any standard GFC API method, or add it to a container widget, without calling ref(). This is because object methods that take a Gtk::Object as an argument will call ref() on the object and take ownership. The same goes for containers. So as a general rule you don't need to call ref() on a Gtk::Object unless you specifically need to hold on to a reference.

Here are a few memory management rules that should be remembered:

If you call operator new to create G::Object you must call unref() on the G::Object when it's no longer required.
You don't need to call unref() on a new Gtk::Object if you pass it as an argument to a standard GFC API function or add it to a widget container.
Otherwise, you only need to call unref() if you first called ref().
Every call to ref() must be accompanied by a call to unref().
Never call operator delete on a GFC object. When you call unref() on a GFC object, delete will automatically be called when the object's reference count reaches zero.
You can ignore the initial reference count for automatic stack objects, but if you call ref() you must also call unref().
Never call unref() on a Gtk::Window. GTK+ owns all top level windows. The correct way to destroy a top level window is to call dispose().

Having remembered all this, there is an easier way to handle an object's initial reference count. GFC provides Pointer<>, a special smart pointer that knows how to handle a GFC object's initial reference count. It also provides automatic memory management similar to std::auto_ptr<>.

What GFC documentation is there?

GFC comes with a complete reference manual and tutorial.

The GFC reference manual is written with Doxygen so if you look at the header files you will find them filled with doxygen comments. If you downloaded the CVS version of GFC you will need Doxygen to compile the reference manual. If you downloaded a tarball version you will find the reference manual pre-compiled in the <docs/reference/html> subdirectory.

The GFC tutorial is being rewritten and should be available soon.

Where will GFC go from here?

GFC will continue to be developed so that it tracks the ongoing GTK+ development, and it will continue to be made available free under the LGPL. At this stage only GTK+ and GConf bindings are implemented, but it is possible more bindings will be added in the future.