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

[Andreas Rottmann <a rottmann gmx at>]

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

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

> 3. libsigc++ 2 needs to be stable when gtkmm 2.4 decides to go stable.
>
I guess this should be feasible.

>> * 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.
>
I didn't mean SigC::Object::manage(), but SigC::manage(obj), which
calls SigC::ObjectBase::set_manage() on obj.

Regards, Andy
-- 
Andreas Rottmann         | Rotty ICQ      | 118634484 ICQ | a rottmann gmx at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.