Re: Broken custom interface implementations with glib 2.36

[José Alburquerque <jaalburquerque gmail com>]

On Tue, 2013-04-02 at 13:02 +0200, Murray Cumming wrote:
> On Tue, 2013-04-02 at 02:53 -0400, José Alburquerque wrote:
> > On Monday, April 1, 2013, Murray Cumming wrote:
> >         With glib 2.36, it looks like we might need to change how we
> >         allow gtkmm
> >         apps to derive/implement custom TreeModels and other
> >         interfaces:
> >         https://bugzilla.gnome.org/show_bug.cgi?id=687659#c6
> >
> >
> > Maybe not.  There may be a way to fix things to allow people to
> > derive/implement the interfaces as they already do even if the glib
> > developers decide to not allow adding interfaces after the class init
> > function runs.  I'll see if I can come up with a patch soon.

I think I've misunderstood.  The problem is that, apparently, the glib
developers consider it a problem to add interfaces to instances of a
class after the class init function of the class has executed.  I
thought that what could not execute before the addition of the interface
was the init function of the interface but that is not the case.

Presently, the only right way I see that this can be done is if,
somehow, the construction of the GObject by the call to g_object_newv()
in the Glib::Object default constructor is delayed until after the
Glib::Interface constructor of the custom class runs because it is by
the g_object_newv() call that the class init function is called.  The
delay might be achievable if we knew for sure that these custom classes
would also use a Glib::Interface constructor but I'm sure this is
probably not the case always.  Presently, changing this looks very
difficult.

The patch I thought of attaching seemed to make the warning and error
disappear for the custom tree model example in gtkmm-documentation
earlier, but now when I test again, the warning and error with a custom
tree model still persist so I wont attach a patch (the concept was wrong
anyway).  I'm sorry.

> >
> Thanks. That would be great.
>
> I have not actually released glibmm 2.36.0 yet, so it can still get into
> the release if necessary.

-- 
José