Re: [gtk-list] Re: gtk C++ signals/slots

[Tero Pulkkinen <p150650 lenkkari cs tut fi>]

--------
Elliot Lee wrote
>On Wed, 23 Jul 1997, Tero Pulkkinen wrote:
>
>> I've been thinking for a while of modifying the current C++ interface
>> of gtk for better use of C++'s features that most C++ compilers
>> already supports -- like templates.  Current version (gtk--) does use
>> too much visible #defines for my taste - Code made atop of gtk-- does
>> not really look like typhical C++ code with all those 
>> METHOD_CALLBACK_EXTERNAL() thingys :)
>
>The METHOD_CALLBACK_* stuff is NOT gtk-specific, it is just one way of
>circumventing C++'s stupidity with regard to callbacks and etc. 

I was thinking of using C++'s builtin features for making those
callbacks properly. I do not agree the comments in gtk--.h about C++'s
stupidity in those things -- there's alot better ways to implement
those callback things than using preprocessor to deal with those!

#defines do just cause confusion -- the syntax (FOO_BAR(a,b)) of them
looks too much function call, even tho it would do something completely
different things than function call or creating an object of class FOO_BAR. 

> You don't
>even have to use my macros - the point of them is to make a way for gtk to
>be able to call a instance method of an object.

why cant you use templates for that?

>templates have absolutely nothing to do with gtk-- IMHO - but prove me
>wrong if you want by providing an example. Just because a language feature
>exists doesn't mean it is applicable in all situations :)

the web page has example of signal/slot implementation using templates.

IMHO its much cleaner than the #defines in gtk--. At least the code using
it looks like C++ code.

(http://www.cs.tut.fi/~p150650/sigslot.html)

>> 2) Is there some things in the current signal/slot implementation of C++
>>    interface that absolutely must be preserved for it to work with gtk?
>>    - signals have name which is used in connecting it to slots. Is it used 
>>      in any other place than making the connection?
>>      - I've been wondering why is that string-format identifier for signals
>>        needed? Maybe same functionality could be made using static language 
>>        consepts.
>
>Strings are more dynamic, and also human readable. And anyways, this is a
>gtk issue, not a wrapper issue... 

okay, I agree with this. So, the string representation for signals is still
necessary for any C++ api too.

>> 4) For future (and existing) gtk widgets there should probably be
>>    parser for converting header file of a gtk widget to create C++ wrapper
>>    for it? (how was the current C++ interface made? writing by hand or
>>    using some generator? -- there's alot of gtk objects available and
>>    it'd be wasted if everyone making a new widget would need to do
>>    interfaces for n+1 different languages)
>
>You can't just convert things automatically. It's not going to work. The
>interface needs to intelligently do conversions of types, and not all
>methods should necessarily be included in the wrapper.
>
>n+1 languages will be easy to handle once we have n+1 maintainers, and a
>more stable Gtk API :-) And, one thing I made sure of in making gtk-- is
>that it doesn't exclude you from using existing gtk stuff in C...

Of course any C++ api must be compatible with the original gtk.

-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --