RE: [sigc] RE: [gtkmm] Roadmap regarding sigc++2
- From: Murray Cumming Comneon com
- To: a rottmann gmx at
- Cc: libsigc-mlist lists sourceforge net, gtkmm-list gnome org
- Subject: RE: [sigc] RE: [gtkmm] Roadmap regarding sigc++2
- Date: Mon, 17 Mar 2003 13:42:53 +0100
> From: Andreas Rottmann [mailto:a rottmann gmx at]
> > 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#.
Yes, I'm thinking of something like that too.
> > 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.
It might not be difficult. We would need to try it.
> >> * How will this effect the memory managment API? ATM there is
> >> SigC::Object and SigC::manage, which are not there anymore in
> >> sigc++2. I guess memory management in glibmm will be purely
> >> GObject-based, then? However, in sigc++2, there is
> >> so I guess this will have to be inherited by GLib::Object.
> > I don't think manage() needs to be in SigC::Object. We can probably
> > just put it in our Glib::ObjectBase class. We don't really use the
> > SigC::Object::manage(), I think, just it's virtual method name.
> I didn't mean SigC::Object::manage(), but SigC::manage(obj),
> which calls SigC::ObjectBase::set_manage() on obj.
Yes, I think I meant set_manage(). We just re-namespace SigC::manage() to
Gtk::manage() now but we could reimplement it easily.
murrayc usa net
] [Thread Prev