Re: .defs Issues From Java-Gnome

[James Henstridge <james daa com au>]

On Tue, 12 Dec 2000, Dan Bornstein wrote:

> 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.

It would be easy to write a small C gtk program that took a list of enum
names as input, and outputs the .java files defining the classes you
require.  This would use g_type_class_ref() to get the GEnumClass or
GFlagsClass structure for a type, and output the class from that info.

> 
> 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?

No one is stopping you from adding support for extra tags to your code
generator.  These things are not set in stone.  I recommend you look at
the new style defs format though.  It makes the class structure of more
explicit, which is probably useful for a java binding.

> 
> 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?"

normal functions/methods are not introspectable.  Signals, types and
args/params are the main ones that you can introspect.

> 
> 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.

Various people have looked at the idea at times, but gtk is almost
definitely not going to switch to generated headers.  It might be useful
to have a program to generate skeletons from a new style .defs file
though.

> 
> >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.

Don't think of boxed types in terms of inheritance.  For gtk 1.2, boxed
types can be thought of as `typed pointers' (for 2.0, it is a little more
complex).  If you have a GTK_TYPE_POINTER argument for a signal, about all
you know is that it is a pointer.  There is not much you can do with an
untyped pointer (the python bindings export them as a cobject, which is
next to useless for python programs).  If you have a GTK_TYPE_GDK_EVENT
pointer, you know you have a (GdkEvent *) pointer, and can treat it
as such.

So think of the relationship between GTK_TYPE_POINTER and
GTK_TYPE_GDK_EVENT as similar to the relationship between (void *) and
(GdkEvent *).

For gtk 2.0, boxed types must also specify copying semantics.

> 
> >>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.

For my binding, I don't try to make the code generator handle
everything.  I have an `overrides' file, which contains wrappers for
functions that the code generator couldn't handle.  This includes some
functions that take special types like this, ones where it makes sense to
convert an `out' argument to a return value, or ones that have to deal
with callbacks.

> 
> 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.

Well, in most cases, it is more convenient for C programmers to have the
various widgets return GtkWidget*.  In my binding at least, they get cast
again pretty quickly.

> 
> >> * Argc/argv issues.
> >In the python code generator
> 
> I think something got cut off in your reply there.

oops.  What I was going to say is that this is another place where you may
want to override what the code generator would usually do.  It may make
more sense in java to have an init(String argv0, String argv[]); function
rather than init(int argc, String argv[]); function anyway, as the length
is determined from the array.

> 
> >> * 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.

I handle this one in python by calling gtk_item_factory_create_item once
for each entry with different callback_data each time.  Once again, a
place where you probably want to override what your code generator would
usually do.

Yes, there are places where not enough user_data arguments are given
though (usually in the various gnome libraries though -- not so much in
gtk).

> 
> >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?

For C programs, gtk 2.0 is not that different, and many programs will
compile with little or no modification.  However, there is a new
type/object system (libgobject), and language bindings should use it
directly rather than the code left for compatibility in libgtk.

> 
> 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.

You should look at both branches though.  I stopped work on the
extension-class-branch a while back, so there are some bug fixes to the
code generator in HEAD that aren't in that branch.

James.