> > Hmm... but how can I hook into the marshalling code to add this hack?
>
> well, that's why this idea is so dirty --- you don't.
>
> $src->signal_connect (new_file => sub {
> my ($object, $thing, $data) = @_;
> my @list = hackish_list_conversion_function ($thing);
> ### ^^^^^^ this is the hack ^^^^^^^^
> 1;
> }, $data);
>
> because i really can't think of another way.
Hrm... I see. Well, I suppose I could implement my own signal_connect
method for GstObject which implements the above hack if the signal is
named "new_file". Basically, it could do something like:
sub signal_connect
{
my ($object, $signal, $callback, $data) = @_;
my $attached_callback = $callback;
if ($signal =~ /^new_file$/i)
{
$attached_callback = sub {
my ($object, $data) = @_;
my @list = hackish_list_conversion_function($data);
$callback->($object, \@list);
};
}
Glib::Object::signal_connect($object, $signal, $callback, $data);
}
This would also be semi-extensible, in that if I needed to add other
bizarre exceptions, I could do it here.
> since there's no type information for GLists, you'd have to create a
> small type wrapper, probably a boxed type. it's not much work at all,
> and is quite often done for little special cases. unfortunately, since
> this is a signal you'd have to change the gtype at the time of the
> signal's creation, which means an API change.
Well, the above hack looks like a reasonable solution, and doesn't require
an API change... now I have to decide if it's worth it. :)
> i can't say why GLib doesn't have a GType for lists, but i can imagine
> it wouldn't be very clean --- you'd have to have the GType for the list
> itself, and then another for the items *in* the list. and since the
> list can hold *anything*....
Yes, true, although if you're only filling the list with Glib-derived
objects, you'd be able to determine their types at runtime using the usual
methods. Anyway, whatever the case, I think I might just use the hackish
solution above.
Brett.
|
