Re: .defs Issues From Java-Gnome

[Tim Janik <timj gtk org>]

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

hi dan,

james has already been doing a pretty good job at pointing out solutions
to some of your problems, but i thought it'd be usefull if i elaborated
a bit on the advantages you get when you track 2.0, and libgobject
specifically. (so keep in mind the comments below apply to 2.0 only,
there've been lots of changes to aid language bindings, most of the
issues you raise with regards to 1.2.8 aren't present in the new code anymore).

> * Some enums and flags types have "holes" or are otherwise not the obvious
>   simple increasing sequence from 0 (or 1 << 0).

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

the enums/flags are completely introspectable. the authoritative source
here's really the information available at runtime. gtk goes thorugh
some lengths to parse headers and all of the information provided is
only available at runtime (the .defs is more of a stripped down version
of that information as far as enums/flags are concerned).
so the best thing to do here is to write a code generator that introspects
enums/flags from the runtime information available and puts out the java
code you require (or might even write some intermediate info file if you
want to keep generation to certain stages only e.g. distribution time).
basically, you query the type system about the derived types of
G_TYPE_ENUM and G_TYPE_FLAGS, retrive their classes with g_type_class_ref()
and then walk the GEnumValue definition list to put out code.

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

GtkItemFactoryEntry shouldn't be mapped 1:1 into java. quite some code
in glib/gtk is there for the convenience of C programmers, simply because
they are written in C. think about how you had implemented item entries
in java, write that code, and then manually map that onto GtkItemFactoryEntry
for your glue code.

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

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.
say you want to know how to construct clist, ctree and button, you
first get their assorted classes and then walk their lists of
construct properties:

GType type = GTK_TYPE_CTREE; // _CLIST, _BUTTON
GObjectClass *class = g_type_class_ref (type);
GSList *slist;

g_print ("construction parameters for: %s\n", g_type_name (type));
for (slist = class->construct_properties; slist; slist = slist->next)
  {
    GParamSpec *pspec = slist->data;
    g_print ("  parameter \"%s\", type: %s\n",
             pspec->name,
             g_type_name (G_PARAM_SPEC_VALUE_TYPE (pspec)));
  }

you'll get something like:

construction parameters for: GtkButton
construction parameters for: GtkCList
  parameter "n-columns", type: gint
construction parameters for: GtkCTree
  parameter "n-columns", type: gint
  parameter "tree-column", type: gint

GParamSpec is the base object of a hirachy of different parameter
specification object. depending on they type, some come with default
values and the like, e.g. for int:
struct _GParamSpecInt
{
  GParamSpec    parent_instance;

  gint          minimum;
  gint          maximum;
  gint          default_value;
};
so once you know that the pspec of n-columns is of type G_TYPE_PARAM_INT,
you can access G_PARAM_SPEC_INT (pspec)->default_value.

from that information, it's easy to compose constructors such as:
class CTree
{
  GtkCTree *gtk_ctree;
  CTree (int n_columns = 1, int tree_column = 1)
    {
      gtk_ctree = (GtkCTree*) g_object_new (GTK_TYPE_CTREE,
                                            "n-columns", n_columns,
                                            "tree-column", tree_column,
                                            NULL);
    }
}

normal, non-construct properties are similarly query-able for your
perusal of generating code that interfaces to g_object_set()/g_object_get()
in the same manner.


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

it'd be good to get those back to us (or james if he intends to include his
python defs file in gtk 2.0), owen and me are worse than lazy about updating
that regularly ;)

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

LBs don't need to deal with class method function pointers in 2.0 anymore,
we have closures there. that is, if you create a new signal, you don't
pass in a class-structure offset to a function pointer anymore, but provide
a GClosure that then calls your glue code to invoke the right java function.
same for signal handlers.
granted, there're currently still problems with chaining to parent class
methods from a child class' method implementation via closures, but that's
being worked on.
also, as james said, GClosure is currently only supported by GSignal,
but we're slowly working on extending that, e.g. to use closures to
iterate over the children of a container, or to connect it to idle/
timeout/etc functions from the main loop.

> I found this tidbit in the GDK docs[*]:
> 
>     struct GdkPixmap
> 
>     An opaque structure representing an offscreen drawable. Pointers to
>     structures of type GdkPixmap, GdkBitmap, and GdkWindow, can often be
>     used interchangeably. The type GdkDrawable refers generically to any of
>     these types.

this doc is highly outdated, i'm not even sure it's fully appropriate for
1.2.8 ;)


> 
> -dan
> 

---
ciaoTJ