Re: GtkBuildable type resolver

[Johan Dahlin <johan gnome org>]

Andrew Cowie wrote:
> On Tue, 2007-06-05 at 14:38 -0300, Johan Dahlin wrote:
> 
>> I'm not sure how a language such as Java solves this problem, but a
>> similar solution is required for libglade (glade_xml_get_widget),
> 
> Tangentially, since you ask:
> 
> This was one of the nastier design questions as we re-engineered the
> Java bindings. Working this out was the focus of our 4.0.2 release (in
> essence, there is no good answer to the problem, and I accept that what
> we're doing isn't perfect - but given our other design constraints it
> works really nicely)
> 
> The architecture of java-gnome, being a strongly-typed and
> built-ahead-of-time-so-that-code-completion-in-IDEs-works language
> binding, assumes that we have a file that looks like this:
>         
>         GtkButton=org.gnome.gtk.Button
>         GtkWindow=org.gnome.gtk.Window
>         GtkLabel=org.gnome.gtk.Label
>         GtkFixed=org.gnome.gtk.Fixed
>         GtkReliefStyle=org.gnome.gtk.ReliefStyle
>         GtkFileChooserButton=org.gnome.gtk.FileChooserButton
>         GtkFileChooserAction=org.gnome.gtk.FileChooserAction
>         GtkProgressBar=org.gnome.gtk.ProgressBar
> 
> and so on for all concrete types. This is a mapping from the result of
> g_type_name() [1] to the public API class we have which represents it.
> There are also mappings for primitive types, although they are handled
> differently.
> 
> We output this list [2] when we build the bindings based on (the
> obvious) algorithmic mapping scheme (it's derived from the .defs data,
> actually). This map used at runtime by a running java-gnome app is, at
> the moment, created at runtime by reading this list in. Thus it is not
> entirely inconceivable that a mechanism could be built to register new
> (unknown at bindings generation time) types.

Do you have one list per binding, or one big "metadata database" which
shared between all third party libraries?
Eg, what will happen when I install the GnomeCanvas Java bindings?

> Runtime registration of unknown types isn't really a major interest for
> us at the moment, but I did keep it in mind as one of those things that
> would inevitably pop up sooner or later.

You're likely to run into this "interesting" problem when wrapping
GStreamer which has plenty of types which are not known when you initialize
your program.

Of course it's possible to workaround by having a huge list of all possible
GTypes, but that list will grow quite large if you take all gstreamer
plugins into mind.

Johan