Re: GtkBuildable type resolver

[Murray Cumming <murrayc murrayc com>]

On Thu, 2007-06-07 at 10:41 -0300, Johan Dahlin wrote:
> Murray Cumming wrote:
> > On Wed, 2007-06-06 at 18:24 -0300, Johan Dahlin wrote:
> >>> GladeXml has a lookup_type() vfunc for this, which I added (I think) so
> >>> that we could instantiate gtkmm GTypes rather than GTK+ GTypes. This
> >>> allows GladeXml to delegate the decision to the language binding, which
> >>> can override that vfunc.
> >>>
> >> Is that vfunc still necessary,
> > 
> > Yes. I don't know of any alternative with libglade.
> > 
> >>  I'd like, if possible to avoid adding this
> >> method to the GtkBuilder API, but I can add one if there's no other
> >> practical way of solving that problem in gtkmm.
> > 
> > I'm sure that this is necessary for other language bindings. I do wonder
> > what pygtk does. I assume that it also needs to instantiate derived
> > GTypes.
> 
> PyGObject does this in the following way:
> 
> For each third-party library, require the bindings to register a mapping
> between the GType and a Python class. Add a type qdata reference to the
> wrapping.
> 
> When creating a python wrapper for a GObject, look at the type of the object
> and see the GType has a wrapper associated and use this python class to
> instantiate the python wrapper.

This is how you associate GKT+ GTypes with pygtk classes. We do that for
gtkmm too so we can instantiate wrappers for existing GObject types.

But the reason we actually instantiate derived GTypes ("gtkmm_GtkEntry"
instead of "GtkEntry") when instantiating objects from gtkmm, is that we
need to provide our own callbacks for default signal handlers and vfuncs
while also falling back to the existing callbacks.

But this is a complex issue. Even if you have a different way of
achieving this, we aren't going to change it in gtkmm any time soon. I'd
like the vfunc in the GtkBuilder, please.

> This works in python because all third party libraries are implemented as
> modules where there is a possibility to run some piece of code where the
> GTypes have their wrappers defined.
> 
> I haven't really used gtkmm (or even C++), but a similar scheme should
> be possible to implement, as long as it's possible to tie types and type
> wrappers together during the program initialization.
> 
> Johan
> 
> 
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com