Re: [sigc] RE: [gtkmm] Roadmap regarding sigc++2

[MHL Schulze t-online de (Martin Schulze)]

Am 2003.03.17 12:47 schrieb(en) Andreas Rottmann:
> Murray Cumming Comneon com writes:
>
> >> From: Andreas Rottmann [mailto:a rottmann gmx at]
> >> I would like to know a bit about the transition plan of
> >> glibmm/gtkmm to sigc++2, since this will effect my Yehia and
> >> SigC++ Extras projects.
> >>
> >> * Which versions are envisaged to use sigc++2?
> >
> > I guess we'd like to use libsigc++ 2.0 for glibmm 2.4 and gtkmm 2.4, but
> > it's not guaranteed, and there are some small issues:
> >
> > 1. There seem to be some large API changes in libsigc++ 2 - I'd like to
> > minimise these.
> >
> >    For instance:
> >    - the non-existence of SigC::slot().
> >
> >    - Use of "this", instead of "*this" when connecting
> >    handlers. People already changed for gtkmm 2.4, and I don't look
> >    forward to telling them to change again.
> >
> I guess both of them could be solved by providing a slot() function
> that is as overloaded to the same extent as the previous one and
> simply invokes ptr_fun# and mem_fun#.

True. However we should investigate what the "right" interface is
for mem_fun() anyway - passing "this" or "*this". I don't know the reason
why Karl changed it from "*this" for slot() to "this" for mem_fun() and
would like to have some good guess at least. I'll have a look how
boost's functors work.

> > 2. We need to investigate the low-level libsigc++ API that allows us to do
> > strange connection/disconnection notification things. A simple compile
> > against libsigc++ 2.0 would probably show these.
> >
> Well, this will be a bit harrier I guess. The only notification
> mechanism sigc++2 seems to provide (note that Martin is more intimate
> with the code than me, so maybe I'm wrong here) is when a
> sigc::trackable object goes out of scope (sigc::trackable is roughly
> comparable to SigC::Object in that respect). I guess with sigc++ 1.2
> you could do more voodoo.

I think that it will be easier with libsigc++2 than with libsigc++-1.2.
libsigc++-1.2 has some heavy memory management code for Slot and
Connection objects.

In libsigc++2 we have _copyable_ "closures" instead (I like that name
less and less). A connection can be thought of as a closure that is held by
a signal. If the signal dies or the connection should be released the
closure simply has to be destroyed. This should operate well with glib signals.

Notification of glib signals when a trackable dies and closures refering it
should be destroyed is also very easy: simply install a notification
callback with closure_base::set_parent() when "connecting" a closure
to a glib signal.

Cheers,

  Martin