Re: .defs Issues From Java-Gnome

[Tim Janik <timj gtk org>]

On Tue, 12 Dec 2000, Dan Bornstein wrote:

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

the defs file is mostly interesting for function name definitions as
those are not queriable at runtime. as for signals, their parameters,
object properties, default values, enums etc... do runtime queries, they are
a) more reliable
b) more complete (if at all present in the defs file)

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

boxed was introduced to let language bindings deal with plain C structures,
such as
struct _GtkRequisition
{
  gint width;
  gint height;
};

the type system knows how to store all types in a generic GValue structure,
i.e. ints, objects, widgets, boxed types etc...
therefore, for objects GValue knows about g_object_ref/g_object_unref,
and for boxed types, it knows how to copy/free them.

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

the next stable release will be called 2.0.
there's a huge fraction of LB related changes in 2.0, e.g. GtkArg is
except for some rare compat functions (required for widget C implementations)
replaced by GValue+GParamSpec in 2.0.
the signal system has been rewritten to deal with GClosure etc.
take a look at the headers in glib/gobject/ to learn about all the
stuff you can consider obsolete at the gtk level.

> 
> -dan
> 

---
ciaoTJ