Hi, > On 11/26/06, Pierre THIERRY <[EMAIL PROTECTED]> wrote: > Mostly for curiosity and a bit for proselytism, did you > consider using > another library to manage signals? I used various Boost[1] > libraries > pretty much, and they are very well designed. Most are a very > good > balance between power and ease of use. > > They have a Boost.Signals[2] library that I think gives much > more > flexibility. Specifically, it doesn't force the user to > subclass a > particular class. IIRC, any functor could be used as a > callback.
Er, that's a misconception. sigc++ does *not* force you to subclass from sigc::trackable. You only do that if you want automatic signal management, such as breaking all connections if an object is destroyed. Also, I think you should be able to use any functor as callback with sigc++. sigc::fun_ptr exists mainly to resolve ambiguous cases. In fact, sigc++ was once a proposed implementation of the back then future signaling library in boost. Although that didn't work out, the boost signaling was cleared inspired by sigc++. sigc++ 2.2 even broke the API in order to match boost conventions and style. > Would it be possible to use your library with Boost.Signals? I don't think it would be a good idea if only hal++ switched to boost and the other *mm libraries stay with sigc++. You certainly don't want to use two signal APIs at the same time. If anything, the whole *mm stack should switch in a joint move. Of course, that could only be done at the next big API break. Also, we'd have to make sure that boost provides the hooks required by gtkmm to be able to wrap GTK+ signals transparently. And someone would have to volunteer to do all the work, of course. Cheers, --Daniel _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
