Proposal: An Xfce C++ language binding for GTK+
jcf at tpg.com.au
Sat Oct 9 02:38:01 CEST 2004
Benedikt Meurer wrote:
> Jeff Franks wrote:
>> I don't see GFC surviving on its own. One-man projects seldom do. But
>> I'm dedicated in what I do and I want to continue. I have been
>> thinking about making this proposal for some time because as you said
>> GFC seems to fit well with the Xfce philosophy. My proposal is all or
>> nothing. I would be very happy to see GFC integrated into Xfce, and
>> to help maintain it. GFC would cease to exist as a separate project
>> and could be removed from SourceForge at some point. Once GFC was
>> integrated into Xfce it could be developed in whatever direction was
>> required. I wouldn't have a problem with that.
> Ok, thats a good starting point. In case we all agree on importing
> GFC, I'd say we should import it as a "separate" Xfce module first and
> start to wrap the basic functionality offered by the xfce libs and MCS
> (and/or the new settings system, in case we adopt it). As Jasper says,
> theres no direct need for a C++ wrapper currently, but offering a high
> level language binding could bring more developers to Xfce and besides
> that, its nice to be able not having to write every single piece of
> code in plain C.
Importing GFC as a separate module is the wise thing to do. It could be
kept as a separate downloadable module for an indefinite time, until it
was felt it was time to add it to add it to the Xfce distribution or
> One problem I see, is that we'd not only have to maintain and develop
> the Xfce part of the wrapper, but also the Glib/Gtk/Gdk/Pango part.
> This is not necessarily a bad thing, since we can make important
> decisions of our own, but its a lot of work. I'm very impressed that
> you managed to do this of your own in the past. From what I know
> (please correct me if I am wrong) only Brian and I are used to C++, so
> you'd have to continue to do most of the maintaince work over time.
I'm happy to continue maintaining the GTK+ part. After five years I'm
starting the get good at it now. I would also be happy to help with any
C++ translations as they arise.
> On the gtkmm issue: I know that Murray's team has put a lot of effort
> and time into Gtkmm, and made a good job (mostly). We should maybe try
> to be/stay mostly compatible with gtkmm in a basic way, so we do not
> need to reinvent the wheel with every Gtk+ major release, if thats ok
> with you, Jeff.
GFC is basically API compatible because we both used the same rules to
wrap the GTK C API. The differences are:
- G namesapce instead GLib. I used G because it's the object prefix, as
in GObject, not GlibObject.
- GFC::String not Gtkmm::Glib::ustring
- GFC uses proxy signal functions such as sig_clicked() instead of
- GFC uses proxy property functions such as prop_font() instead of
- Gtkmm preferentialy uses references. GFC uses reference if a function
argument must not be null and a pointer if null is a valid value.
- Gtkmm implements STL-like interfaces for some widgets, GFC doesn't.
- GFC implements virtual signal handlers as a separate signal class
hierarchy that must be multiplely inherited from to override a virtual
signal handler. This is the main reason for GFC's speed and size
improvement over Gtkmm.
Both Gtkmm and GFC use libsigc++ so any Gtkmm programmer should have no
trouble understanding GFC (and vice versa).
> So, if nobody complains, I'd like to start looking into details about
> how, where and when to import GFC after the next 4.2BETA is released.
Perhaps post 4.2.x entirely. I guess that the other Xfce programmers, if
they agreed, would like to keep a back door available if it was felt the
integrated C++ binding didn't measure up in testing.
> PS: I personally *klemmer* the idea of switching the whole desktop to
What does *klemmer* mean?
More information about the Xfce4-dev