RE: signals versus vfuncs

[Murray Cumming Comneon com]

> Christof Petig said:
> > Perhaps widget derivation on the fly (take a base widget 
> and override 
> > just some vfuncs without adding member variables (extending the 
> > instance
> > struct)) should deserve an API ???
> >
> > e.g.
> >    GType modify_type(GType base, const char 
> *new_type_s_name, <list of 
> > vfuncs and implementations>);
> >    void gobject_change_type(GObject *, GType new_type);
> 
> i've tried coming up with something like this, as a custom 
> wrapper for my bindings to use.  it's not easy, and it 
> doesn't seem useful in practice. 

It's exactly what we do for gtkmm, though I'm not sure about the
"on-the-fly" part. Every gtkmm class has a GType that derives from the
underlying C type, so that we can override default signal handlers and other
vfuncs.

> overriding existing vfuncs means you have to have the struct 
> offsets someplace, and you have to know how to marshall them. 
>  with all that, you either need a database of vfuncs and 
> parameter types,

We have hand-written *_vfuncs.defs files. And we have code to generate
*_signals.defs files.

> or custom code all over the place, which 
> means the modifier functions are pointless.  rather than use 
> the database (which would be runtime overhead), i've chosen 
> the code route (maintenance overhead, but faster at runtime).

Hmm, maybe you're doing this anyway and I'm not helping.

[snip]
> will override render when called from perl, but will not be 
> seen when the renderer is used in a TreeView.  instead, you 
> need to do something like this:

I don't know the perl details, but I really feel that it should be possible
if you override the vfunc in a C Gtype. In C++ we store the associated C++
wrapper instance in the C Gobject instance with g_object_set_data(). So then
we have everything that we need to do our own funky C++ stuff in response to
that C vfunc call.

Murray Cumming
www.murrayc.com
murrayc usa net