Re: gtk_signal_connect_interp()

[Owen Taylor <owt1 cornell edu>]

Marc Ewing <marc@redhat.com> writes:

> Owen Taylor <owt1@cornell.edu> writes:
> > > 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).
> 
> Is there a "legal" way to obtain the data pointer for a signal
> handler during the destroy so I don't have to keep a table of
> those data pointers around anywhere?

The "poor man's" way of doing this would be to use the fact
you can have multiple "destroy" handlers. So you could simply
create a destroy handler for each other handler you set up.

  gtk_signal_connect (object, "clicked", my_function, my_data);
  gtk_signal_connect (object, "destroy", g_free, my_data);
 
In general, this is not going to be very efficient, but if
you are passing the _same_ data to all callbacks for a certain
widget, (a common case), then it is pretty natural.

> It seems to me that this would be a generally useful (optional)
> feature of signal handlers.  Often times I find myself wanting
> to stick some data in the data bit, and then forget about it
> forever.  Passing a function as an argument to gtk_signal_connect()
> (or something variant) that can handle the data cleanup would
> make this easy to program.

Agreed. Assuming nobody objects to my proposal too much, it will
probably be in 0.99.4. 

Regards,
                                        Owen