Re: [gtk-list] Re: Signal and event management.

[Havoc Pennington <rhpennin midway uchicago edu>]

On Thu, 3 Dec 1998, Enric J. wrote:
> 
> What I need essentially is a way to extend the signal mechanism in Gtk
> without using signal_connect, or without the overhead of the signal_connect
> mechanism, I need a way to pass ALL GTK SIGNALS to my own objects, think
> for a while that If I have a form with let say 200 controls and I want to
> be able to process some of the signals in an OO way without knowing in
> advance what signals to call, I must to ask Gtk for a signal_connect for
> all 200 controls for all Gtk signals (a medium of 60 for object), that's
> about 12000 signal_connect calls, an overhead I want to elude.
> 

See Tim's answer, or you can use the Gtk-- approach.

This is what Gtk-- does, maybe it will help to understand the source: 

All widgets have an associated Class struct, that has a function for each
signal or virtualized operation (not all of them are signals). Gtk-- takes
the normal contents of this struct, and saves it somewhere else. Then it
installs its own custom functions which basically chain the signal out to
the C++ object via a method called signal_name_impl(), which by default
calls the original C function we saved, but can be overridden by user
subclasses. 

This is all set up by a preprocessor which parses special "macros" like
SIGNAL_SPEC() in the .gen_h files, and creates the necessary _impl method,
replacement function to put in the Class (signal_name_callback), and
generates the struct where we will save the original C functions
(Gtk_c_signals_Name). 

The way to figure it out is to look at say widget.gen_h and then
widget.h/widget.cc, to see what's generated.

Havoc