Conceptual Question on Signal Handling in Subclasses

[Ian Flanigan <flan lean to>]

Hey folks,

I started hacking with GTK not long ago and I'm in the midst of
putting together my first real application.  Everything is going well,
but there is one conceptual question that still nags.  To put it
simply, "How do I make signal handlers overridable (virtual) in GTK?"

Here's what I mean: I have two object classes, X and Y.  If I want, I
can set an instance of Y to receive signal S from an instance of X as
follows:

    gtk_signal_connect_object( x, "S", y_handle_signal_S_func, y );

This works great.  When x emits signal S, y's signal handler gets
called.  But what if I want to connect an instance of X to an instance
of Z, which is a subclass of Y that wants to override Y's version of
y_handle_signal_S_func?

One option is to set up a signal in Y (and therefore its subclasses,
including Z) that is the same as (or at least corresponds to) the
signal in X.  Then I could do something like:

    gtk_signal_connect_object( x, "S", y_reemit_signal_S_func, z );
    ...
    void y_reemit_signal_S_func( GtkObject *x, GtkObject *y )
    {
       gtk_signal_emit_by_name( y, "S", x );
    }

and then handle Y's version of S in the default handler, which could
be swapped out for Z's subclass-specific version.

Or I could just make it virtual from the get-go:

    gtk_signal_connect_object( x, "S", Z->y_handle_signal_S_func, z );

What is best way to this in GTK?

The big question, I suppose, is how to make objects that can talk to
each other in a way that allows subclasses to handle things
differently from the base class.  In C++ you'd use virtual functions,
for example.

The reason I'm asking is because I'm trying to implement a
Model-View-Controller scheme in my program where the view can be
changed to one of many different implementations on the fly.  Because
I am very much connecting objects together (instead of connecting
objects to some functional framework), I really need to use something
akin to virtual functions since I'm never sure what the underlying
object will actually be.

Thanks a bunch,

Ian Flanigan