sigc++ signals by default will call every attached slot. they are wrapped by other objects when used in conjunction with GObject signals so that signals for which (e.g.) a boolean-true return value will stop emissions actually works at the C++ level too.
sigc++ by itself does not have this behavior by default. i've never tried to use sigc++ signals to emulate the way they are used to wrap GObject signals. On Thu, Apr 18, 2013 at 7:49 AM, אנטולי קרסנר <[email protected]> wrote: > I know, but I want to have default handlers using pure libsigc++ which > behave like gtkmm. Currently my implementation calls the virtual > methods, and these emit the signals, so overriding them works more or > less like overriding in gtkmm: the derived class is the only handler of > the signal. > > The question is: Does this technique result in behavior similar to the > behavior of gtkmm? > > On ה', 2013-04-18 at 07:00 -0400, Paul Davis wrote: > > > > > > > > On Thu, Apr 18, 2013 at 2:55 AM, אנטולי קרסנר <[email protected]> > > wrote: > > Hello, > > > > I'm a gtkmm user and I'd like to write signals for some of my > > classes. I > > noticed gtkmm widgets have default handlers, which are virtual > > protected > > class methods. I want my classes to have them too for > > consistency, but I > > couldn't figure out from the source code, how exactly they are > > implemented. > > > > > > don't confuse the use of sigc++ to wrap GObject signals with using > > sigc++ signals "from scratch". > > > > > > adding your own signal to a class is as simple as adding a declaration > > like: > > > > > > sigc::signal0<void> mySIgnal; > > > > to the class declaration. such a signal has no handlers unless things > > connect to it, and no notion of a default handler. > > > > > > > > >
_______________________________________________ gtk-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-list
