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

[Elliot Lee <sopwith redhat com>]

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

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

> Now I have few questions:
> 1) Is it reasonable thing to do?
>    - There already is a working(?) C++ interface, is there need for
>      another one? 

My nicer side says "It's a free world, go ahead", my darker side says [not
when I'm willing to improve gtk-- to do what you need :-]

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

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

-- Elliot					http://www.redhat.com/
What's nice about GUI is that you see what you manipulate.
What's bad about GUI is that you can only manipulate what you see.