Re: [sigc] RE: [gtkmm] Roadmap regarding sigc++2
- From: Andreas Rottmann <a rottmann gmx at>
- To: Murray Cumming Comneon com
- Cc: libsigc-mlist lists sourceforge net, gtkmm-list gnome org
- Subject: Re: [sigc] RE: [gtkmm] Roadmap regarding sigc++2
- Date: Mon, 17 Mar 2003 12:47:18 +0100
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.
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.
] [Thread Prev