Re: gtk_signal_connect_interp()




Marc Ewing <marc@redhat.com> writes:

> I've got a question about using gtk_signal_connect_interp() vs
> using gtk_signal_connect().  From what I've been able to figure
> out (and from everything I've looked at, nobody uses
> gtk_signal_connect_interp() at all),

It's mainly used in interpreted language bindings.

> if I need to have the
> data portion of a signal handler freed or taken care of in some
> way when the handler is removed, I need to do something like:
> 
>  gtk_signal_connect_interp(GTK_OBJECT(item), "expand",
>                            expand_tree, s, g_free, FALSE);
> 
> (where the data, s, is the result of a g_strdup()).  Is this
> correct?  Does gtk_signal_connect_interp() do more than that?
> Is there some other way to accomplish what I need?

Hmmm. Right now, this won't work, because gtk_signal_connect_interp
expects the function to be a special marshall function instead of an
everyday garden-variety signal handler.  I discussed solutions to this
problem with Marius a few months ago, but nothing came of it.

For now, the right thing to do is to free your data in the "destroy"
callback (and if you gtk_signal_disconnect anywhere explicitly, also
free it there). GTK only removes signals handlers without external
prompting when an object is destroyed.

The capability would be nice in other circumstances, though -
particularly for language bindings that don't want the full 
marshalling capability (because they are statically typed),
but would still like to know when the callback data is destroyed.

I'll post a separate summary of what I was discussing with Marius -
Now that I've been reminded of the issue, I'd like to put in
a solution before 1.0. (It is going to break language bindings 
- since 0.99.4 is already going to do that, now is probably a
good time.)
 
> Is there someplace other than the source I should be looking that
> explains all this?

Not really. If you want to learn the nitty-gritty of _connect_interp,
guile-gtk is the place to look, but I don't think it would help
that much to do what you are trying to do.

Regards,
                                        Owen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]