Re: Default signal handlers



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, אנטולי קרסנר <tombackton gmail com> 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, אנטולי קרסנר <tombackton gmail com>
> 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.
>
>
>





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]