[sigc] Re: Using libsigc++2 in a GTK+ C++ binding

[martin-ml hippogriff de]

Am 17.10.2003 um 15:31 Uhr haben Sie geschrieben:
> Hi,
> 
> I've been looking at libsigc++2. Very impressive API!
> The best I've seen. I have been looking at the possibility
> of using a 3rd party C++ callback library in the next
> release of the Integrated Foundation Classes (another
> C++ binding for GTK+). I have looked at the boost
> signal libary and several other smaller signal libraries but
> think libsigc++2 is be the better choice. I have one
> problem with using libsigc++2 and was hoping you could
> help me out.

We will do our best. However, you are also invited to join the gtkmm
developer team. So far Inti looks like some kind of clone with no clear
distinction from gtkmm to us (which used to be different in the days of
gtkmm-1.x, admittedly).

> 1. Using libsigc++2 seems pretty straight forward. I
> would derive the class heirarchy's most primitive base
> class from sigc::trackable so that any slots created in
> dervied classes will be automatically destroyed
> when the class gets destroyed.

Yep. Maybe it is reasonable to use a protected inheritance since
sigc::trackable has no virtual dtor which would be a problem if someone
tried to manage his data with a list of sigc::trackable* ...

> 2. The problem I have is with writing the GObject/GTK+ > signal
wrapper classes. In libsigc++-1.2 there was
> separate SigC::Connection and SigC::ConnectionNode
> classes, so SigC::ConnectionNode could be derived
> from to provide a specialized node class for GObject
> signals. This allowed a SigC::Connection class to be
> returned by GObject/GTK+ signal connect methods, just
> like the SigC::Signal connect methods. In libsigc++2 a
> sigc::connection class is constructed from a 
> sigc::slot_iterator<> reference, and
> functor::internal::slot_base* is private, so the 1.2
> technique wouldn't be possible with libsigc++2. The
> only option I can see would be to make the GObject
> signal wrappers a set of completely independant classes
> that return there own connection class. Does this sound
> reasonable?

It sounds reasonable. However, since libsigc++2 is also devoted to
future versions of gtkmm and the API is not stable yet things might
change when we try to solve these issues for gtkmm which will soon be
the case (hopefully this weekend).

> 3. I like the standard libary style adhered to in libsigc++2,
> including 'sigc' instead of 'SigC' and the small-letter class
> names. I have one question though. Why 'sigc::functor'. I
> noticed in the TODO file it was mentioned whether or not
> the functor classes should be moved into the sigc
> namespace. I have to admit I would prefer that option.
> Did you decide against this?

No, I'd prefer having everything in one namespace, too, but was waiting
for more input on this. Murray wanted to make up his mind with the
class reference at hand. Unfortunately the documentation doxygen
produces still looks like a mess and at the moment I have no idea how
to improve it.

Regards,

  Martin