Re: Missing drag'n'drop methods in GtkTreeView

["muppet" <scott asofyet org>]

muppet said:

> we can't just return the value from get_search_equal_func, because it may not
> be ours!  in general, we would check that the installed function is our custom
> marshaller and if so return the code reference inside the callback....
> however, get_search_equal_func gives us no way to get to the user data
> associated with the callback.  to support this, we'll have to store another
> copy of the callback someplace, which now gives us the opportunity to get out
> of sync and thus cause bugs and memory leaks.

to clarify for those playing along at home:

to wrap a function that takes a callback, you pass in generic SVs for the func
and user_data.  we then create a GPerlCallback with the proper param types and
store the code reference and user data scalars inside it.  then we install a
private marshaler which invokes the callback, and pass the GPerlCallback
object to that private marshaler in the normal user_data slot.  sneaky, eh?

if it's a function that only needs the callback for the duration of its
execution, we destroy the callback before returning from the xsub.

however, it it's a function that *installs* a callback for later use, then we
have an object lifetime issue.  most well-behaved APIs offer a way to add a
destruction notifier so you can clean up your user_data when the function is
replaced.  we have to hook into that.  if that's not available, then you have
to jump through other hoops to make sure the right thing happens.


if you're thinking, hey, wasn't GClosure invented to solve this problem? 
well, yeah, it was, but the problem is that there are lots of APIs (in gtk,
gnome, and doubtless in your own libraries) that don't play nicely with
GClosure.  the most common problems i've seen are the lack of a destroy
notifier and the lack of GClosure-compatible marshalling.


now, if that makes sense, it will go into the developer's docs.

-- 
muppet <scott at asofyet dot org>