Put g_signal_connect() back!

[Owen Taylor <otaylor redhat com>]

  Thu Mar  8 16:35:48 2001  Tim Janik  <timj gtk org>

	* gsignal.[hc]: fixed accumulator invocation, implemented emission
	hooks. and no, neither of these callbacks are called via a closure,
	language bindings can wrap the accumulator and emission hook
	interface, they already get parameters marshalled into a GValue array.
	(g_signal_connect): removed this function as its C specific, doesn't
	cover the swapped argument, is too close to its broken original
	gtk_signal_connect() and creates demand for _swapped, _after and
	_swapped_after variants <brrr>.
	(g_signal_connectc): convenience macro to connect a C handler
	func with data, like the old g_signal_connect() plus swapped
	argument.

 - g_signal_connect() will probably be the common function call in 
   GTK+ programs. It doesn't need an extra c, or an extra argument.

 - Language bindings will all have their only ways of doing signal
   connection. They will do this by special case code. Should
   perl have connectpl that connects a perl subroutine 
   python have a connectpy that connects a python function,
   guile have connects that connects a scheme closure? Of course
   not. All languages should have a ::connect() that does the
   right thing for the common case.

 - What was broken about gtk_signal_connect(). That it was easy to use?

 - I don't think it would hurt at all to have more variants of 
   g_signal_connect(); they are even macros, so you can't event 
   complain about bloat. However, we don't _have_ to give in
   to that demand. Having the general case and the common special 
   case doesn't mean you have to have every other special case as
   well.

 - Why does g_signal_connectc() create less demand for variants?
   Because it's so ugly that nobody would ever want anything
   else that looks like it?

Thanksm
                                        Owen