Re: .defs Issues From Java-Gnome

[James Henstridge <james daa com au>]

On Tue, 12 Dec 2000, Dan Bornstein wrote:

> Hi there. I'm one of the developers working on the Java-Gnome project (see
> <http://java-gnome.sourceforge.net/> for details if you are unfamiliar with
> it). 
> 
> I sent a note (attached below, mostly for historical interest) a couple
> days ago, and it seems to have gotten lost in "moderation purgatory," so I
> took extreme measures, and joined the list so I could post directly.

There is also the post-only list you can join if you need to send
occasional mails to various gnome/gtk lists :)

> 
> Right now, I'm the primary developer of the .defs file processing code for
> Java-Gnome, and I wanted to let you know about some issues we've had. Since
> writing the original note, I did some spelunking through the archives and
> found discussions from January and February of this year about redoing the
> format for the .defs files, but I was unable to find anything after that,
> so I don't really know where things currently stand.

I am using the new defs format for the gtk 2.0 rewrite of the python
bindings without much trouble.  I added support for specifying the default
value for an argument and whether NULL is an acceptable value, which make
the binding nicer to use.

> 
> That being said, I wanted to share with you some of the problems we've had
> dealing with the current .defs format. (If these concerns have already been
> addressed with the new format, then that's great, and I apologize for
> wasting your time.)
> 
> * 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.

> 
> The Java code for an enum/flags type ends up being a class which declares
> static variables to hold each of the enum/flags constants. For example
> (simplifying somewhat for the sake of explanation):
> 
>     public class GtkAccelFlags
>     {
>         static final public int VISIBLE = 1 << 0;
>         static final public int SIGNAL_VISIBLE = 1 << 1;
>         static final public int LOCKED = 1 << 2;
>     }
> 
> Right now, if the underlying C type is declared in anything but the same
> order as declared in Scheme or if the C type assigns values in something
> other than the typical order, then we will get messed up. Since we *must*
> be able to have these as manifest constants in Java (to support switch
> statements and the like), right now, what I will be forced to do is grovel
> over the actual C headers to derive these values, which will be a big pain
> in the ass, and seems counter to the whole .defs idea anyway.
> 
> * There are inheritence relationships with some things currently classified
>   as "boxed types".
> 
> I'm thinking in particular of the GDK types GdkDrawable, GdkBitmap,
> GdkPixmap, and GdkWindow. There are C-level declarations that make it
> look like there should be an inheritence relationship where GdkDrawable
> is the superclass of the other three, but this isn't expressable in
> the original .defs format. (Java-Gnome has our own extension at this
> point, which is covered in the original note, below, but it may not
> be applicable now.)

GdkDrawable, GdkPixmap and GdkWindow (and a number of the othe GDK
types) are no longer boxed types in gtk 2.0.  They are GObjects, just like
GtkWidgets are.  So your defs file shouldn't class them as boxed types.

For gtk 1.2.x, these are all the same type, despite the different names
(although some methods don't make sense to be applied to some types of
drawables).

> 
> The upshot of this is that it seems that the boxed vs. object distinction
> is somewhat dubious.

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

> 
> * We need to deal with read-write structs. 
> 
> There are structs like GtkItemFactoryEntry which we need to be usable from
> Java. Right now, it looks like (fields ...) forms are meant to imply that
> the fields are read-only, so we'd need an extension that allowed one to
> declare read-write fields. (We have an extension that supports just that.
> Again, given the evolution of the format, it may not be applicable
> anymore.)

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.

> 
> * 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. In this
> case, we use the fact that the name ends with "_new" as the determining
> factor and then spit out a warning saying that the return type doesn't
> match. However, there are cases of constructors (mostly in Gnome, I think)
> that don't have names that fall into any obvious heuristic. In those cases,
> we rely on the return type, and in fact have to change the .defs file to
> make the processor recognize a constructor as such.

The new defs format has a (is-constructor-of ...) clause that can be put
into a function's declaration.  This makes things more explicit, and you
can go through and find the weirdly named constructors in your .defs file
and fix them.

> 
> * Argc/argv issues.
> 
> Java main()s don't get the program name in argv[0], so in order to make
> Gtk.init() (or Gnome.init()) do something reasonable from the Java
> perspective, we have to secretly insert a zero-th element to the argv array
> on its way into GTK. (And, not that it's your issue per se, but it looks to
> me like the Gnome init code assumes that argv[0] can't be freed.) We
> currently define two special Scheme types, "argvec" and "argcnt" to handle
> the mechanism. (For example, argcnt is just like "int" except that it gets
> incremented by 1 on its way to GTK.)

In the python code generator

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

> 
> * Function pointers aren't good enough.
> 
> There's no such thing as a function pointer, per se, in Java. The closest
> one gets is an interface with a single method. However, there's no easy way
> to translate that into a function pointer at the lower level. I noticed
> some rumblings on the list about implementing closures. If one could in
> fact create a closure (either generate a trampoline or use a special type)
> that were usable wherever function pointers are currently used, then life
> would be much happier up in Java Land. (Okay, so this isn't really a defs
> issue, but I thought it was worth mentioning.)

Closures do make things easier to handle.  Take a look at the closure type
defined in gobjectmodule.c in pygtk (HEAD branch in cvs).  Although, use
of GClosure is pretty much limited to the new signal code for now.

Is the (function/marshaller, user_data, destroy_notify) triple that is
used almost everywhere else not enough for java?  Granted you may not be
able to generate the wrapper for a function that takes these arguments
automatically, but it should not be too difficult to handle.

> 
> Thanks for listening, and I look forward to your responses. Since I'm set
> up to receive this list in digest form, if you want a quick(er) response,
> please reply to me directly.

If you are doing a gtk 2.0 binding, feel free to look at my python
bindings (gnome-python/pygtk in cvs, HEAD branch).  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.  Feel free to make use of
the ideas and maybe even some of the code generation stuff found there.

James.