is a powerful multi-platform toolkit
for creating graphical user interfaces. Written completely in C, it
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.
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
encapsulation, inheritance and
polymorphism to make it easy for programmers to develop and reuse GFC
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
these, and others, in the bindings
page on the GTK+ web site.
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
use all the concepts they're already familiar with.
Some other goals for the GFC project are:
- Stable interfaces, with an easy upgrade
- Judicious use of the standard C++ library
- Automatic memory management to help
prevent memory leaks.
- Consistency; to make GFC easier to learn,
religiously follow strict conventions.
- Ease of use; GFC gives you a
package, with all the interfaces you need.
- Documentation; stable releases of GFC
will have excellent
- Maturity; GFC will not be maintained as a
library; it will support features as they become mature.
relationship between GFC and GTK+?
| GTK+ is
C toolkit that comprises several component libraries. These include:
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+.
- 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
use GFC instead
of plain GTK+?
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.
does the GFC
development platform include?
includes C++ wrappers for most of the features implemented in the GTK+
package. These include:
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
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.
- A GUI widget toolkit.
- An Accessibility Toolkit for writing
programs for the
- Internationalized text handling.
- Main loop support.
- A new virtual signal system optimized for
execution speed and performance.
- A standard string compatible UTF-8 string
- A widget demonstration program.
- Example and test applications
- Full documentation.
does GFC improve
on plain GTK+?
a number of essential C++ features:
- Namespace support
- Type safety, no need for type casting.
- Use of C++ native types such as string
- Automatic memory management.
- Derivation of new widgets using standard
- 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
is behind GFC?
| GFC is
being developed by The GFC Development Team. Currently the primary
maintainer is Jeff Franks.
is GFC licensed?
|GFC is licensed
under the GNU Library or Lesser General Public License (LGPL), similar
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.
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
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
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
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.
project was renamed Inti: Integrated Foundation Classes,
after the abandoned project of the same name on which GCode was based.
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
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.
does GFC differ
from the other C++ language bindings for GTK+?
are several differences:
- GFC has a new virtual signal handler
system which is optimized for size, execution speed and
is judicious in its use of C++ language features, which also improves
- 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
- 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
and slots that
is an alternative to the new virtual signal handler system mentioned
- GFC uses automatic C++ memory management
based on the GTK+ reference counting system.
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
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
a lot of criticism of C++, most of it unfounded, and usually
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.
does the new GFC
virtual signal system work?
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
signal handler gets
called, which usually does nothing but call the default GTK+
handler. What a waste! Then there is the huge virtual function table
that each widget inherits, filled with 70+ entries, and the overhead
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.
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
class, or one of its base signal classes. For example, to customize
main window by overriding one or more Gtk::Widget signal handlers you
would derive your window class like this:
class MyWindow : public Gtk::Window, public Gtk::WidgetSignals
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
interfaces and don't include widget header files. The other thing to
note is that the Gtk::WidgetSignals constructor takes a widget pointer
its only argument. This enforces type safety and simplifies the
does GFC memory
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()
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().
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
rule you don't
need to call ref() on a Gtk::Object unless you specifically need to
hold on to a reference.
a few memory management rules that should be remembered:
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<>.
- If you call operator new to create
G::Object you must call unref() on the G::Object when it's no longer
- 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
be called when the object's reference count reaches zero.
- You can ignore the initial reference
for automatic stack objects, but if you call ref() you must also call
- 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().
documentation is there?
|GFC comes with a complete
reference manual and tutorial.
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>
tutorial is being rewritten and should be available soon.
will GFC go
|GFC will continue
to be developed so that it tracks the ongoing GTK+ development, and it
continue to be made available free under the LGPL. At this
only GTK+ and GConf bindings are implemented, but it is possible more
bindings will be added in the future.