Re: g_signal_connect_swapped

[Lance Dillon <riffraff169 yahoo com>]

----- Original Message ----
From: Matt Hoosier <matt hoosier gmail com>
To: Richard <rileyrg googlemail com>
Cc: gtk-app-devel-list gnome org
Sent: Sunday, November 26, 2006 6:44:13 PM
Subject: Re: g_signal_connect_swapped

On 11/25/06, Richard <rileyrg googlemail com> wrote:
> Could someone explain the reason for this function
>
> "g_signal_connect_swapped"
>
> I have read the manual here:
>
> http://www.gtk.org/tutorial/x159.html
>
> where it says:
>
> ,----
> | g_signal_connect_swapped() is the same as g_signal_connect() except that
> | the instance on which the signal is emitted and data will be swapped
> | when calling the handler. So when using this function to connect
> | signals, the callback should be of the form
> |
> |
> | void callback_func( gpointer   callback_data,
> |                     ... /* other signal arguments */
> |                     GtkWidget *widget);
> |
> | where the object is usually a widget.
> `----
>
> Could anyone express this a little clearer? I (as a gtk beginner) can
> see no reason for it.

This just means that the "widget" and "callback_data" pointers will be
pushed onto the call stack in the opposite order from their ordering
if hooked up with g_signal_connect(). If you're designing your own
callback function, this probably isn't useful; just use
g_signal_connnect() with a callback that has GObject* and gpointer
parameters [in that order].


---------------------

I've used it for a couple of different things.  One, if you aren't concerned with the widget that it is 
concerning, then you can used _swapped() and have your user_data first, and not worry about where the widget 
is, somewhere at the end of the argument list.  Or another thing is with language bindings.  I'm writing the 
language binding for pike, and in the signal marshaller I'm taking the arguments and actually rearranging 
them kind of different, so that the pike funciton gets the widget, the user_data, then an array of the rest 
of the arguments.  This way the user can get the user_data at arg2, regardless of the number of other args 
there are.