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

[Jeff Franks]

Brian J. Tarricone wrote:

>On 10/08/04 21:17, Jeff Franks wrote:
>  
>
>>Brian J. Tarricone wrote:
>>
>>    
>>
>>>i think [source compat] would be a big win,
>>>as it sounds rather silly to have two competing language bindings.  i mean,
>>>really, competing software, sure.  competing toolkits, sure.  but competing
>>>bindings for the same toolkit?  kinda silly, IMHO.
>>>
>>>
>>>      
>>>
>>Sometimes when there are conflicts you have no choice but to either do 
>>it yourself or don't do it all.
>>    
>>
>right, i certainly understand.  sometimes what exists can't be modified
>enough to your satisfaction, so you start from scratch.  but is there a
>good reason, for example, to call it sig_clicked() rather than
>signal_clicked()?  for three more keystrokes, you gain a little more
>compatibility for no measurable loss (unless you're as lazy as i am).
>  
>
There was a reason but it could be changed if the 'signal_clicked' 
syntax is preferred. sig_clicked() is an instance specific proxy signal 
function that calls the real static signal 'clicked_signal', passing it 
a 'this' pointer. This syntax was inherited from Havoc's original source 
code. I never changed it because I thought the syntax 'sig_clicked() and 
clicked_signal' was clearer than  'signal_clicked() and clicked_signal'. 
I guess it doesn't matter as clicked_signal is protected and intended 
for internal use only. Users would have no need to connect directly to a 
static clicked_signal.

>since i've never written a lang binding before, i can't say with certainty,
>but it seems like you could have designed your binding API such that it
>could be a drop-in replacement for gtkmm.
>  
>
One problem. The Gtkmm guys will be on your back asking: 'Instead of 
writing an Xfce binding that is Gtkmm source compatible why not just use 
Gtkmm', or 'Why do you need a C++ binding when Gtkmm already wraps 
GTK+'. The Gtkmm FAQ accuses my binding  of 'tracking Gtkmm2' which 
annoys me no end. I began writing GCode (the original version) long 
before work  on gtkmm2 began. I even helped Murray solve a few problems 
implementing the C++ wrappers for GObject/GTypeInterface as I had 
already solve these problems in GCode. I felt sharing was a good idea.

I'm not sure that 100% drop-in source compatibility with Gtkmm is a good 
idea. If this is done, then 'drop-in source compatibility' becomes the 
benchmark. This could stifle innovation and *Joe  Klemmer* will 
undoubtedly say 'we can't do that because it's not drop-in source 
compatible Gtkmm. Eventually all you end up with is a cut-down version 
of Gtkmm?

>i don't want to sound like i'm telling you how to write your software, but
>i really hate to see fragmentation, especially when it seems like it's
>possible to be compatible without much of a loss.  at least that way it'd
>be a lot easier to get gtkmm converts...
>
>  
>
Agreed, but the main  advantage for Xfce having its own C++ binding is 
that Xfce can control the way its binding develops and evolves, and Xfce 
would have no 'indirect dependancy' on another library (such as Gtkmm). 
The are not many differences between GFC and Gtkmm but there is one 
difference I didn't mention: memory management. In GFC the 'smart 
pointer' and memory management are tied together and are incompatible 
with Gtkmm. To change this would mean rewriting GFC's memory management. 
Also there are C++ features that GFC doesn't use: STL-like interfaces 
and C++ exceptions (it does use one in its implementation of operator 
new), but Gtkmm uses them extensivley. Surely drop-in source 
compatiblity requires compatibility to be absolute, 100%. If there is 
one incompatibiltiy surely there may as well be more. I happy to narrow 
the API gap for source compatibility with Gtkmm but it could never 100% 
compatible.

If GFC integration is agreed we should  hack out a list of  changes 
needed (plus maybe any preferred coding/style guidelines), acceptable to 
everyone. That way its implementation will be right from the start.

Jeff.