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.
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.
AfC
Sydney
[1]: incidentally, this points out a future-tense concern I have for
non-Glib libraries like Cairo - it may be tricky for us to figure out
what type an arbitrary pointer actually is if there is no g_type_name()
equivalent there. I don't really know enough about Cairo to know whether
this will be an issue or not; certainly at bindings generation time we
*do* know the type of each parameter / return value, so the more general
dynamic lookup we use for GObjects and GBoxeds can be replaced with a
more specific lookup as necessary (that's what we need to do for enums,
as it happens).
[2] This reminds me that I need to actually write the 4 lines of code to
do this into the code generator this week :)
Attachment:
signature.asc
Description: This is a digitally signed message part