Re: .defs Issues From Java-Gnome

[Dan Bornstein <danfuzz milk com>]

Thanks again to everyone for your input so far. It's extremely helpful.

James Henstridge writes:
>> * Some enums and flags types have "holes" or are otherwise not the obvious
>>   simple increasing sequence from 0 (or 1 << 0).
>
>Yes, this info is not in the defs files.  However, it is available at
>runtime to your program. If you have part of your code generator written
>in C, you could query the GType system for the values for the various
>constants.  This would probably be more reliable as well.

Yeah, I suppose that can be done, but it strikes me as the wrong way to go
about this. I thought the idea of the .defs files was to provide a
language-neutral-ish format that contained everything needed to generate
bindings. I think I have a compelling case for having the values associated
with enum/flags types to be there. Yes, I can work around the lack, but I
would view this as a workaround, not a long-term solution.

In particular, our generator is currently all Java, and straying from that
ends up adding complexity. JNI (the Java Native Interface) is a pain in the
butt to use, and a HUGE pain in the butt to code for manually (which is
what I'd have to do to do what you suggest). I'm actually more inclined to
avoid linking Java with GTK *while* building the bindings (I mean, that's
what the output's supposed to be for!), and just generate a C program that,
when run, emits parsable output defining all of the enum/flags values.

Put another way, if the defs files contain this information, then the
*only* files I need to build bindings are the defs files. If they don't,
then I need a working (at least to some extent) GTK distribution. I'd
rather be totally data-driven.

Pretty please? How bad would it be if elements in define-enum forms took an
optional "(= ...)" clause?

Taking another tack for a moment, how much of what's in the defs files
*isn't* covered by some sort of runtime introspection functionality? That
is, if I wrote a program that took no input but could make GTK calls to its
heart's content, and it output something like defs files, what would be
missing in the output compared to the current information in the defs
files? Is it worth aiming for the answer to be "none?"

Taking one final tack on the topic, has there been any recent thought given
to the concept of using the defs files as the authoritative source and
generating the C headers from them, rather than the other way around? It
seems that there's a lot of expressiveness in the defs format that gets
lost in the C form, and comment-directives are pretty cumbersome to write
and hard to read.

>Boxed still has pretty much the same meaning as before.  Just that some
>types that were boxed types are now objects.

I guess I'm unclear on what "boxed" is really supposed to mean. My
interpretation was something like "superclassless object-like thing with
explicitly named copy/free methods." It seemed like it'd be simpler to add
the concept of a superclassless define-object and add optional object
attributes for the copy/free methods. (They could even be done as virtual
methods.)

But indeed, I was totally confused by GdkDrawable and friends, so my
perspective is probably skewed.

On a similar topic, have GdkEvent et al been sorted out in a similar
manner? It looks like they're in dire need of inheritence in 1.2.8.

>>There are structs like GtkItemFactoryEntry which we need to be usable from
>>Java.
>For the python implementation, I represented some of these things with
>native python types (eg. lists and tuples).  Don't know what would be best
>for java.

For the python bindings, how do you generate the translations between the
native python form and the underlying struct? I'm really hoping that that
can be an automated defs-driven process, and not something to code by hand.

BTW, if you're curious, check out

    <http://condensed.milk.com/~danfuzz/java-gnome/JNIProps.txt>

for the current incarnation of all of the type translations done in
Java-Gnome. If possible, I *only* want this file to contain translation
patterns for the fundamental types. I'd hate to add a new custom
translation for each struct type.

>>* Bad constructor return types.
>The new defs format has a (is-constructor-of ...) clause that can be put
>into a function's declaration.

Yay! It'd still be nice if the GtkWindow constructor were actually
declared to return a GtkWindow and not a GtkWidget, though.

>> * Argc/argv issues.
>In the python code generator

I think something got cut off in your reply there.

>> * Lots of missing definitions.
>> 
>> I think we've probably had to double or maybe even triple the size of
>> the .defs files compared to the ones found in the 1.2.8 distribution.
>
>The one in the gtk distro is not up to date, and I don't know of any
>language binding using it as a definitive source.  It is mainly used by
>the build system to generate code that registers all the enums and boxed
>types.

In the future, I think it'd be ideal if the binary distribution included
what was considered reasonably up-to-date defs, so that one wouldn't have
to get the source just to build bindings. (In this sense, I see the defs as
sorta like the symbol table in a library; you don't need the source code to
link to a library.)

>> * Function pointers aren't good enough.
>
>Is the (function/marshaller, user_data, destroy_notify) triple that is
>used almost everywhere else not enough for java?

It's *almost* good enough. (I didn't write the callback stuff, so I
probably have some details wrong, but...) We use a single function pointer
and stuff an object in the user_data representing the object and method to
call (and any user_data that the Java user wants). Most of the time, it's
no big deal to do the appropriate munging when adding a callback (etc.).
However, there are a few pernicious calls like this:

    void gtk_item_factory_create_items (GtkItemFactory *ifactory,
                                        guint n_entries,
                                        GtkItemFactoryEntry *entries,
                                        gpointer callback_data);

where the function pointer (GtkItemFactory[n].callback) and data
(callback_data) aren't passed as a unit. I have no idea how to meaningfully
translate that into Java without being able to put a closure into
GtkItemFactory[n].callback.

>If you are doing a gtk 2.0 binding, feel free to look at my python
>bindings (gnome-python/pygtk in cvs, HEAD branch).

Well, right now, we're just trying to work with 1.2.8, as that's the most
recent stable release. Also, once again I have to claim a bit of ignorance;
is the next stable version supposed to be 1.4 or 2.0? How much similarity
is there between 1.2.8 and 2.0? Is it different enough to obsolete a
significant fraction of our work so far? How soon after 1.4 gets released
does it look like 2.0 will become stable?

In any case, I'll probably take a look at how the python bindings work.
(Thanks for the reference.)

>There is also a branch that uses the new defs format and is targeted at
>gtk 1.2 -- the extension-class-branch of the pygtk directory.

Ah, that sounds more promising for the shorter-term needs of Java-Gnome.

Take care, and thanks again.

-dan