- What is GTK+?
- What are the Xfce
- How has XFC evolved?
- What are the goals of XFC?
- What is the relationship
between XFC and GTK+?
- Why use XFC instead of GTK+?
- What does XFC include?
- How does XFC improve on
- 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?
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.
The Xfce Foundation Classes (XFC) is a set
of well integrated C++
classes that wrap the functionality provided by Xfce and GTK+ into a
light-weight, 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.
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
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.
The main goal for the Xfce Foundation
Classes is to implement a
light-weight, fast and easy to use C++ interface for the Xfce and GTK+
libraries. Some other goals are:
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.
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 provide a compact but comprehensive C++
around the GTK+ libraries. XFC judiciously uses C++ language features
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++".
The Xfce Foundation Classes includes C++
wrappers for most features
implemented in the GTK+
package. These include:
The Xfce Foundation Classes adds a
number of C++ features:
The differences between the Xfce Foundation
Classes and other C++
language bindings for GTK+ include:
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:
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 class header file. This is
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.
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
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 XFC
using 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 of it. 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:
Currently there are two modules in the Xfce
Foundation Classes, the
core object system and utility library (libXFCcore) and the user
interface library (libXFCui). A third module is planned (libXFCde)
the functionality provided by the Xfce libraries.
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.
libXFCde provides C++ class wrappers for the
GTK+ objects implemented by the Xfce libraries. libXFCde depends on
libXFCcore and libXFCui and should become
available some time in the next few months, once Xfce 4.4 development
starts to progress.
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
Stacks! The documentation can be found in
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