RE: [gtkmm] Roadmap regarding sigc++2

[Murray Cumming Comneon com]

> 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.
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.
3. libsigc++ 2 needs to be stable when gtkmm 2.4 decides to go stable.

> * When are these lined up for release? (I expect only a *very* vague
>   answer here, of course ;-)

The first versions will be released when glib and gtk+ 2.3.0 are released.
The stable versions should be released soon after gtk+ 2.4.0 is released,
approximately 8 months from now.
 
> * 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 sigc::trackable,
>   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.

Murray Cumming
murrayc usa net
www.murrayc.com