Re: GtkBuildable type resolver

[Tristan Van Berkom <tvb gnome org>]

On Tue, 2007-06-05 at 14:38 -0300, Johan Dahlin wrote:
> Tristan Van Berkom wrote:
> > On Mon, 2007-06-04 at 16:04 -0300, Johan Dahlin wrote:
> [..]
> > One thing that might or might not be a can of worms is
> > language bindings. I wonder if someone more experienced
> > than myself in this realm could point out how we plan
> > to load widgets written in other languages from the GtkBuilder
> > perspective, namely how will we obtain the runtime GType of
> > the object from its name in the xml/glade file.
> 
> Python avoids this by registering all the types as soon as you load the
> bindings. However this is unfortunately memory wise and might be changed
> in the future.
> 
> However, this would be quite easy in a dynamic language like python where
> it is feasible to register the wrappers when they first are accessed.
> I'm not sure how a language such as C++ or Java solves this problem, but a
> similar solution is required for libglade (glade_xml_get_widget), which both
> languages appear to support.
> 

Not sure I understand, glade_xml_get_widget() gets a widget that was
already constructed by libglade (and its binding may do other fancy
stuff like create a language specific wrapper for that object). Assuming
the widget comes from gtk+, this poses no problem, but when the derived
widget was written in python or C++, how does libglade build the
object in the first place ?

Must the calling application call a binding to
glade_xml_register_widget() ? (sounds reasonable enough...).

Also, if the calling application uses language specific objects,
I suppose its ok to demand that they be registered with the type
system before parsing a UI file ?

Other than demanding that types be preregistered (which is the
case with python at the moment anyway which you pointed out), it might
be reasonable to add a lookup_type() vfunc to the builder itself 
(as Murray pointed out he did with libglade) - allowing a C++ or Python
derived builder to instantiate the correct types based on the type
identifier string in the UI description file.

Cheers,
                    -Tristan