Re: GtkBuildable type resolver



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 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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]