Re: [[gtkmm] Accessing a sigC++ signal]

[Paul Davis <pbd op net>]

>Wow. Bummer. I don't know what to say. I certainly can't complain,
>because I wasn't around to give input as to the direction that gtkmm 1.3
>should take. Unfortunately, my entire code revolves around sending
>signals everywhere.
>
>I've got a custom color dialog and when you select a color from within a
>drawing area, it then emits a signal that the sliders and other widgets
>receive and then update themselves. Also when a slider is updated, the
>drawing area is signalled to update as well. Other widgets are the same
>way. I came to gtkmm because I like C++ over C, but I stayed because of
>the ease with which you can subclass a widget to create your own widget
>and the power in libsigc++. I emit signals, I connect signals to other
>signals, I bind all kinds of extra data to callbacks, etc. To me,
>emitting signals is not only not rarely necessary, it is essential.
>
>Well, with that said, I must ask what is the "Right" way to do these
>things? I guess I'll have to reluctantly rewrite my program (again!) so
>I might as well do it correctly this time.

i think there is a misunderstanding here.

its perfectly fine to emit SigC++ signals:

    SigC::Signal0<void> foobar;  // declare it.

    foo();     // emit it
    foo.emit() // also emit it

the response about not emitting GTK+ signals was, i believe, rooted in
the idea that you wouldn't emit GTK+ style signals (as opposed to
SigC++ style signals, which are not the same at all). if you need to,
just drop to C and use 

     gtk_signal_emit (GTK_OBJECT(cpp_widget.gobj()), "signal_name", ...);
     

the key point here is that the SigC++ signals in the codebase of gtkmm
(as opposed to any that you create for custom widgets) *wrap* the GTK+
ones, and emitting a SigC++ signal that wraps a GTK+ signal doesn't
emit the GTK+ one as well. by contrast, when the GTK+ signal is
emitted, the SigC++ one that wraps it *will* be emitted. is that clear enough?

--p