Re: Subclassing Gtk2::CellRenderer

[muppet <scott asofyet org>]

On Wednesday, October 1, 2003, at 10:50 AM, Bjarne Steinsbø wrote:

> A method invocation in GObject is just a signal, right?  So I should 
> override the proper signal name in order to let my own routine handle 
> this method.

i wish it was just that simple.

yes, the only way to do proper virtual overrides from perl is to supply 
a new handler for an existing signal.  this is because of some really 
strange things about how GObject is implemented, and the fact that we 
can't find the struct offset for every method *and* its call signature 
without a lot of extra work.

but this only works if the method you want to override has a signal 
associated with it.  according to teh body of GtkCellRendererClass in 
gtkcellrenderer.h, it's just a vtable --- the function pointers aren't 
associated with signals.

so...


> However, when I try to install an overridden method (uncommenting line 
> 7 in "MyRenderer.pm") the way I think method overriding is to be done, 
> I get an error message saying "can't override class closure for 
> unknown signal render at ...".  Where am I going wrong?

well, you aren't going wrong, there just is no signal associated with 
that method.

now to be perfectly honest, the render method would be called a *lot*, 
so they probably assume that you'd have to be insane to want to 
implement that in a non-c or c++ language.  given that i can't see a 
way to attach a widget to the treeview and you'll probably wind up 
rendering something that looks like an optionmenu by hand, i can't say 
that i really fault them for that assumption.

if you don't mind having a little bit of extra XS for your custom 
cellrenderer, i think you can pull it off a little more easily by 
mixing C and perl.

sorry.

--
muppet <scott at asofyet dot org>