Re: gtkmm 3.0.

[Krzysztof Kosiński <tweenk pl gmail com>]

2010/3/25 Chris Vine <chris cvine freeserve co uk>:
> On Thu, 25 Mar 2010 09:46:08 +0100
> Murray Cumming <murrayc murrayc com> wrote:
>> I'm sorry for not taking the time to consider this discussion fully
>> right now, but I do want to revisit it properly for gtkmm 3. I hope to
>> have time later. Right now, I'm not putting much thought into gtkmm 3
>> because it's not clear when the (silly, unnecessary, IMHO)
>> ABI-breaking GTK+ 3 will happen, giving us the (blameless)
>> opportunity to do gtkmm 3.
>>
>> Even if we don't change this, I hope we'll have the big discussion
>> again (like we did for gtkmm 2) so we know why we've decided whatever
>> we decide.
>
> While we are on the subject of gtkmm-3, can I make one other suggestion
> in addition to weak pointers, which will help safe and sane programming
> with gtkmm far more than discussing whether a particular object is held
> by smart pointer or not. That is for gtkmm to provide its own
> thread-safe sigc::trackable class which can interface with the rest of
> libsigc++.

+1
There are a few severe bugs in libsigc++ which require breaking ABI,
such as the performance on slot removal bug (libsigc++ walks the
entire list of slots whenever one is removed).

I think sigc::trackable should have protected virtual functions for
its slot management operations, so that gtkmm can override them to
implement thread safety using GMutex; this would avoid adding a
dependency on Glib or Boost to libsigc++.

Regards, Krzysztof