Re: [gtkmm] General C++ Design Question: relation of GUItoapplication

[Paul Davis <pbd op net>]

>So I don't understand how one would write a signal - I suppose it is some lowe
>r level
>work  that  is done in preparation for the use of slot().  I just take the slo
>t()'s
>that appear in the gtkmm1.2 examples as god-given.   Could someone refer me to
> the
>examples for writing signals?

there is nothing to it.

one of the problems with the Signals&Slots terminology is that it
leads people who understand callbacks in C into thinking its some
whole new thing. its not.

Signals are just ways to execute a set of registered callbacks.
Slots are just the objects used to store the registered callbacks.

Suppose you want to provide a way for interested parties to be told
that something changed in your model:

     class Model : public SigC::Object {
       public:
         SigC::Signal0<void> SomethingChanged;
     };

this means that all callbacks (slots) that you want called when this
signal is "emitted" must return void and take no arguments. You
register callbacks ("connect a slot to a signal") very simply:

	class InterestedParty : public SigC::Object {
	  public:
	    void onModelChange();
        };	    

	Model           theModel;
        InterestedParty anInterestedParty;
	      
	theModel.SomethingChanged.connect 
		(slot (anInterestedParty, &InterestedParty::onModelChange));

Now, when something does in fact change in the model, you "emit" the
signal. This just means that we'll call all the registered callbacks:

	theModel.SomethingChanged(); 
OR
	theModel.SomethingChanged.emit()

the two forms are provided for your convenience - there is no
difference between them in any way. in both cases, every callback
registered ("every slot connected to the signal") will be called.

SigC++ takes care of object lifetimes - if you delete
anInterestedParty (if it were in fact on the heap, that is), then
SigC++ will take care of making sure its no longer connected to
the SomethingChanged signal of theModel, etc.

--p