Re: Put g_signal_connect() back!

[Tim Janik <timj gtk org>]

On 8 Mar 2001, Owen Taylor wrote:

> 
>   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.

gtk_signal_connect_object() is used about as often as gtk_signal_connect()
if not even more frequently. the problem with gtk_signal_connect() in the
first place was that you require a bunch of function variants to get
full connection functionality, g_signal_connect_data() finally breaks with
that.

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

at the very least gtk_signal_connect() should have had a swapped
argument, purely due to the frequent use of swapped data connections.

so ideally, we'd have:

guint    g_signal_connect                     (gpointer           instance,
                                               const gchar       *detailed_signal,
                                               GCallback          c_handler,
                                               gpointer           data,
                                               gboolean           swapped);

now, however, since it is purely a C language function, and with
g_signal_newc() we already did language specific postfixing,
so i did that for g_signal_connectc() as well.
also it's at least mildly confusing for g_signal_connect()
to have a different prototype than gtk_signal_connect(), so
that was another reason to name that function differently.

saying we need a g_signal_connect() with the old signature, because we
have gtk_signal_connect() doesn't count on my list though, because
gtk_signal_connect() was broken in the first place.
and arguing for frequent use is counterproductive for your standpoint
since that's exactly why a swapped argument is required.

that being said, i'm not too opposed to do
s/g_signal_connectc/g_signal_connect/, _i_ will not get confused
about the swapped argument, i'm just worried about users who might.
doing that however, should trigger reevaluation of the naming for
g_signal_newc().
either way, i am opposed to repeating the gtk_signal_connect()
failure in the GSignal API.

> 
> Thanksm
>                                         Owen
> 

---
ciaoTJ