Frequently Asked Questions
Table of contents
- What is GTK+?
- What are the Xfce
- How has XFC evolved?
- What are the goals
- What is the
relationship between XFC and GTK+?
- Why use XFC instead
- What does XFC
- How does XFC improve
- How does XFC differ
from the other C++ language
bindings for GTK+?
- How does the XFC
virtual signal class system work?
- How does XFC memory
- What modules
does XFC distribute?
- How is XFC
documentation is there?
What is GTK+?
GTK+ is a powerful graphical
user interface library originally designed
for the Linux platform. Written completely in C, it comprises a
collection of graphical objects, such as buttons, menus and
the function calls needed to implement them. The graphical objects are
known as widgets and the collection of widgets is known as the GIMP
toolkit or the GTK+ widget set.
What are the Xfce Foundation Classes?
The Xfce Foundation Classes (XFC) is a set of well integrated C++
classes that wrap the functionality provided by GTK+ into a
light-weight and easy to use application framework. Such frameworks are
called language bindings. Here are some other C++ language bindings you
might be familiar with:
There are many language bindings available for GTK+, including C#,
Java, Objective-C, Guile, Perl and PyGtk. You can find more information
on these and others in the bindings
page on the GTK+ web site.
- the Gtkmm package is a
high level C++ encapsulation that
includes the use of exceptions, STL-like widget interfaces, template
classes and offers both automatic memory management and normal C++
memory management techniques.
- the VDK/VDKBuilder
package, which is a Borland-like builder
for rapid application development. VDK is a C++ wrapper for GTK+.
VDKBuilder is a general purpose integrated
development environment for constructing GUI applications using VDK.
VDK was built as the base library for VDKBuilder and therefore
implements an object hierarchy and API more suited to rapid application
- the wxWindows/GTK
package, which is a free C++
library for cross-platform GUI development. Currently it supports MS
Windows, Unix with GTK+, Unix with Motif, and Mac OS.
How has XFC evolved?
The Xfce Foundation Classes is not a new library but rather the latest
incarnation of a stable library that has been in development for the
past 5 years. XFC started out as the GCode library in early 2000,
about the same time that GTK+ development version 1.3.1 was released.
Unfortunately for GCode there was a CAD program of the same name, so a
new name had to be found, not an easy task! Havoc Pennington was
approached and he kindly agreed to let GCode use the name Inti,
originally a set of C++ foundation libraries written by him but no
longer in active development. Inti was the original library on which
GCode was based.
Under the new project name, Inti: Integrated Foundation Classes,
stable versions up to 1.2.0 were released. During the development of
the Inti 2.0 source code base it was decided to change the project name
to GTK+ Foundation Classes, to better reflect the library's usage as a
GTK+ language binding. To get this name Inti had to merge with two
abandoned projects, GFC: GNU/GTK Foundation Classes and GFCLIB: GNU/GTK
Foundation Classes. GFC 2.3.1 was the only release made under the newly
merged project. Prior to its first stable release GFC became a part of
the Xfce project.
A lot of time has been spent developing the GFC source code base,
which had been a 'one-person' project. With the source code now mature
and stable the time was right for the library to become part of a
larger project, to assure its continued development. The Xfce Desktop
Environment was the obvious choice because many of its goals were
similar. Under the new name: Xfce Foundation Classes, the library is
now an integral part of the Xfce project. Compared with the early days,
the source code base has continually improved and evolved to the point
now where XFC is essentially a complete rewrite; almost none of the
original source code is left.
What are the goals of XFC?
The main goal for the Xfce Foundation Classes is to implement a
light-weight, fast and easy to use C++ interface that adheres to the
GTK+ programming paradigm, so programmers can continue use the concepts
they're already familiar with.
Some other goals are:
- Only implement essential C++ features.
- Stable interfaces, with an upgrade path that follows the
Xfce Desktop Environment release cycle.
- Use of the standard C++ library features.
- Automatic memory management to help prevent memory
- Consistency; to make XFC easier to learn, the interfaces
religiously follow strict conventions.
- Ease of use; XFC gives you an integrated package,
with all the interfaces you need.
- Documentation; stable releases of XFC will have excellent
- Maturity; XFC will not be maintained as a 'bleeding edge'
library; it will support features as they become mature.
What is the relationship between XFC and
GTK+ is a C toolkit that comprises several component libraries. These
The Xfce Foundation Classes wraps these libraries in a consistent and
easy to use C++ interface. XFC should be immediately familiar to most
GTK+ programmers because it uses the same widget hierarchy, and the
same API names and identifiers.
- 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
Why use XFC instead of GTK+?
Over the years application programming has become more complex. Today,
C++ is a better way the manage that complexity because it provides you
with a variety of programming 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.
The Xfce Foundation Classes is a compact but comprehensive C++ wrapper
around the GTK+ library. XFC judiciously uses C++ language features and
does not layer on too much extra C++ complexity. Its API is easy to
understand and use, and should feel immediately familiar to most GTK+
programmers. Throughout its development XFC has maintained a good
balance between remaining faithful to GTK+ and remaining faithful to
C++. Hence the catchphrase - "the power of gtk+, the power of c++".
What does XFC include?
The Xfce Foundation Classes includes C++ wrappers for most features
implemented in the GTK+
package. These include:
- A GUI toolkit
- An Accessibility Toolkit for writing programs for the
- Internationalized text handling.
- Main loop support
- A signal system.
- A UTF-8 string class.
How does XFC improve on GTK+?
The Xfce Foundation Classes adds a number of 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 XFC.
- Full wrapper for all C types, including enumerations and
- Typesafe C++ signal system based on the new libsigc++ 2.0
- Widget signal classes that minimize the overhead of
implementing large numbers of virtual signal handlers.
How does XFC differ from the other C++
language bindings for
The differences between the Xfce Foundation Classes and other C++
language bindings for GTK+ include:
- The use of virtual signal classes which are optimized for
size, execution speed and performance.
- The judicious use of C++ language features to improve
- Minimal use of exceptions, leaving the decision whether or
not to use exceptions optional and up to the user.
- No STL-like widget interfaces; to avoid adding extra layers
of C++ object code and risking a bloated interface.
- The use of the new libsigc2 callback library to implement a
typesafe system of C++ signals and slots as an alternative to the
virtual signal classes.
- The use of automatic C++ memory management based on the
GTK+ reference counting system.
How does the XFC
virtual signal class system work?
Most C++ language bindings put widget virtual signal handlers, all 70+
of them, directly into their respective widget classes. This hooks each
virtual signal handler directly into the GTK+ signal emission chain. As
a result, every time a GTK+ widget signal is emitted the corresponding
virtual signal handler gets called, which usually does nothing but call
the default GTK+ signal handler. What a waste! Each widget ends up with
huge virtual function table filled with 70+ entries, and the overhead
needed to call them. And that's just for one widget. Multiply that by
the widgets in your application and it starts to add up.
The pre-eminent goal for the Xfce Foundation Classes was to implement a
virtual signal handler system that overcame these problems. It took
some time to develop but the result is impressive. Now there is real
potential for smaller, faster applications, depending on your C++
programming style. So how does the virtual signal class system work? In
XFC, all widget
virtual signal handlers have been moved into an abstract signal class
hierarchy. To override one or more widget signal handlers a custom
widget class must multiplely inherit from its 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:
using namespace Xfc;
class MyWindow : public Gtk::Window, protected
on_delete_event(const Gdk::EventAny& event);
on_configure_event(const Gdk::EventConfigure& event);
on_expose_event(const Gdk::EventExpose& event);
The on_delete_event(), on_configure_event() and
on_expose_event() signal handlers are all inherited from
Gtk::WidgetSignals. One thing to note here is that the widget header
must be included before the widget signal header file. This is because
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 XFC memory management work?
The Xfce Foundation Classes uses GTK+ reference counting to manage the
memory of its objects. This ensures that the principles of memory
management are kept consistent across the GTK+ and XFC libraries, and
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 XFC
the corresponding functions ref() and unref().
Most XFC objects can either be created dynamically on the heap or
automatically on the stack. When you create a XFC 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 released 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 releasing its initial reference count by calling
One thing to note about Gtk::Objects. You can pass a newly created
Gtk::Object as an argument to any standard XFC 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 want to hold on to a reference.
Here are a few memory management rules that should be remembered:
- If you call operator new to create a G::Object you must
call unref() on the object when it's no longer required.
- You don't need to call unref() on a new Gtk::Object if you
it as an argument to a standard XFC API function or add it to a widget
- Otherwise, you only need to call unref() if you first
- Every call to ref() must be accompanied by a call to
- Never call operator delete on a XFC object. When you call
on a XFC object, delete is automatically called when the object's
reference count reaches zero.
- You can ignore the initial reference count for automatic
objects, but if you do call ref() on one you must also call unref().
- Never call unref() on a Gtk::Window. GTK+ owns all top
windows. The correct way to destroy a top level window is to call
- Having remembered all this, there is an easier way to
object's initial reference count. XFC provides Pointer<>, a
special smart pointer that knows how to handle a XFC object's initial
reference count. It also provides automatic memory management similar
What modules does XFC distribute?
Currently there are two modules in the Xfce Foundation Classes, the
core object system and utility library (libXFCcore) and the user
interface library (libXFCui), but other modules are planned.
libXFCcore wraps the GLib object system and selected objects from
the GLIb utility library. Essentially it provides a low level object
system that can be used to build other libraries; libXFCui depends on
this library. libXFCcore uses the new libsigc++ 2.0 callback library to
implement a system of signals and slots which make using native GObject
signals or creating your own signals easy. There is a standard string
compatible UTF-8 string class, reference documentation and several test
libXFCui combines the power of GTK+ and the power of C++ into a
state-of-the-art user interface toolkit that makes developing
GTK+ applications in C++ easy, intuitive and efficient. There are more
than 420 classes that wrap most of the objects found in the ATK, GDK,
Gdk-pixbuf, GTK and Pango libraries. Included is a full set of simple
example programs, a C++ version of the GTK+ widget demonstration
program, extensive reference documentation and a new tutorial.
How is XFC licensed?
The Xfce Foundation Classes 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 XFC; however you should read the license yourself (or have your
lawyers read it), in order to get all the details about your rights and
What documentation is there?
Stacks! The documentation can be found in the <doc>
subdirectory where the Xfce Foundation Classes was installed, usually
for stable releases. There are four kinds of documentation: this FAQ
sheet, the API reference manual, a new tutorial and numerous widget
HOWTOs with examples.
The API reference manual is written with Doxygen, so if you look at the
header files you will find them filled with doxygen comments. The XFC
tutorial takes you step-by-step through the process of writing three
simple XFC applications. Then using one of these programs, XfcApp, it
shows you how to write a feature packed main window that can be used as
a starting point for any application. The tutorial finishes up by
building XfcApp into GNU compliant autotols project with international
language support. New to XFC are the numerous widget HOWTOs, one for
most widgets, that discuss how each widget is used and works through a
© 2004-2005 The XFC