Re: GtkBuildable type resolver

[Johan Dahlin <johan gnome org>]

Murray Cumming wrote:
> 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.

Fair enough, I'll add it.

Johan