Re: .defs Issues From Java-Gnome

[Dan Bornstein <danfuzz milk com>]

Thanks again, everyone. I am feeling a little overwhelmed with information,
right now, but I hope I can sort it all out in the not-too-distant future.
For now, just one reply to a comment that caught my eye:

Tim Janik writes:
>> * Bad constructor return types.
>> 
>> There seem to be a proliferation of declarations like this:
>> 
>>     GtkWidget* gtk_window_new (GtkWindowType type);
>> 
>> That is, the declared return type from a constructor isn't actually the
>> most-specific type that's returned. Right now there are a few heuristics
>> used by our processor to determine what constitutes a constructor. [...]
>
>going for the _new() functions to figure constructors is a bad idea
>for language bindings. basically, there's one generic constructor for
>objects: g_object_new(). that function optionally takes object properties
>and also construction parameters. the construction properties are
>introspectable at runtime, so here again, a code generator will get
>you all you want.

That looks pretty promising. My main concern with this approach is that the
results will likely prove surprising to someone who is trying to program in
Java based on the C-oriented GTK documentation. (The nominal Java-Gnome
approach to documentation thus far has been to be extremely regular in our
translations and just refer to the C-oriented docs.)

This is also my concern about *not* translating
gtk_item_factory_create_items in some form or other. I know there will have
to be exceptions to at least some stuff, but I'd like very much to keep it
to a minimum. So, I'm trying to push the boundaries here and stop only
where something *really* must be done specially. (This hopefully also saves
development time in the long run.)

My current inclination (which I've yet to discuss much with the rest of the
Java-Gnome group) is to continue to just use .defs files to do our
generation, at least for now, mostly because we already have a large hunk
of mostly-working code that's oriented toward that approach, and that
approach is much simpler than relying on a working, running GTK library to
run queries against. We *will* have to deal with the enum/flags issue one
way or another, but I don't want that to really affect anything else much.

If I do anything having to do with introspection, I'd actually be most
interested in having a standalone utility that could introspect GTK and
spit out (a slice of the) .defs files (everything but function definitions,
perhaps?). Like the .defs files themselves, this tool would likely be
useful to *many* language bindings, and it'd keep development simple
because the language binding generator wouldn't have to be directly linked
with GTK.

If it looks like we can get the new-style .defs to get spit out reliably
for 1.2.8, I'll probably start working on a parser for that form sooner
rather than later, but, if not, I'll probably sit tight with the old .defs
until there's a stable 2.0 release.

Later,

-dan