Proposal: An Xfce C++ language binding for GTK+

[Jeff Franks]

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 
discard it.

>
> 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 
signal_clicked().

- GFC uses proxy property functions such as prop_font() instead of 
property_font().

- 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.

>
> regards,
> Benedikt
>
> PS: I personally *klemmer* the idea of switching the whole desktop to 
> C++.

What does *klemmer* mean?

Jeff Franks