Re: Dispatch of GObject virtual functions in GtkMM

[Daniel Elstner <daniel kitta googlemail com>]

Am Sonntag, den 28.01.2007, 21:10 +0100 schrieb Daniel Elstner:
> 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.

Bah, I'm a bit too fast with the Reply button today, it seems.

There's a potential problem with this hack:  changing the vfunc pointers
of the class changes them globally, thus affects every gtkmm widget in
your application and assorted libraries.  So you should probably pass a
custom type name to Glib::ObjectBase() to avoid this.

--Daniel