Re: Dispatch of GObject virtual functions in GtkMM

[Murray Cumming <murrayc murrayc com>]

On Sun, 2007-01-28 at 21:09 +0100, Daniel Elstner wrote:
> Am Sonntag, den 28.01.2007, 13:53 -0600 schrieb Matt Hoosier:
> > On 1/28/07, Daniel Elstner <daniel kitta googlemail com> wrote:
> > >
> > > Well, if you subclass the GObject as you would in plain C without gtkmm,
> > > it's of course possible to wrap the result as a non-custom widget in
> > > gtkmm.  Is that what you meant?
> > 
> > Not quite. I had something more like this in mind:
> [snip]
> >             CustomWidget ()
> >             {
> >                 static bool lazy_init_done = false;
> > 
> >                 if (!lazy_init_done)
> >                 {
> >                     GtkWidgetClass* klass = < macros to fetch class
> > object for this new GType > ;
> >                     klass->expose_event = CustomWidget::expose_event;
> >                     lazy_init_done = true;
> >                 }
> >             }
> 
> That will probably work, though it's of course a hack.  I don't expect
> any problems on the gtkmm side though, at least if Glib::ObjectBase(0)
> is used.  Deriving a custom GObject class would be cleaner though.

It's definitely no problem when vfuncs and default signal handlers have
been disabled in the gtkmm build. For vfunc overrides it's what you
_should_ do in that case. For signals (expose_event is a signal, I
believe) you still have the option of connecting a signal handler, but
overriding the default signal handler as above is also OK.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com