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

[Brian J. Tarricone]

On 10/09/04 00:38, Jeff Franks wrote:

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

now that i read this (after my last comments), i'm understanding some of
the compatibilities better.  but still, the function name changes are silly
and unnecessary.  i like the idea of using the 'G' namespace, but i feel
like that just makes it easier for some other, unrelated lib to conflict at
some point in the future.  not that it's your fault, but a little more
typing will save you that.

the other stuff i can't argue with ^_~.

	-brian