Re: GtkBuildable type resolver
- From: Johan Dahlin <johan gnome org>
- To: Murray Cumming <murrayc murrayc com>
- Cc: Andy Wingo <wingo pobox com>, gtk-devel-list gnome org
- Subject: Re: GtkBuildable type resolver
- Date: Thu, 07 Jun 2007 10:41:25 -0300
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]