Re: [gnome-bindings] Redefining the defs format =)

[James Henstridge <james daa com au>]

On Sun, 15 Apr 2001, Mark Patton wrote:

> First of all, it's great to see some discussion here. I tried at least
> once to get some sort of discussion going on improving the defs format
> without any success.
> 
> I've been working on Tcl bindings for Gtk 2.0 for a while now. Because
> noone here seemed interested in cooperating I ended up defining my own
> format, but if there was an authorative definition I would certainly
> use it and help with maintenance.

I guess I only really told people about my work on the pygtk and
gtk-devel-list lists and irc.  If anyone else is looking for help writing
bindings, hopefully this list will be a good starting point.

A snapshot of my bindings is available at:
  http://www.gnome.org/~james/pygtk2-SNAP-20010408.tar.gz

It will require python >= 2.0, glib and gtk+ >= 1.3.3 to compile.  There
are some dynamic linker problems at present that will cause some
difficulty in actually using the bindings.  Patches are available at:
  http://bugzilla.gnome.org/show_bug.cgi?id=50707

> 
> For every public C function I need:
>  - the name (available)
>  - the class it belongs to (available)
>  - the C return type and arg types (available)
>  - the GTypes correpsonding to those C types (not available ?)
> 
> I can go from the C type to the Gtype with a fair degree of accuracy
> using various heuristics, but it's ugly. Perhaps instead of including
> the GTypes with every function we could just define a mapping from
> the C type to the GType. The defs format seems to have some provision
> for this, with "type", but it doesn't seem to be used in gtk.defs

You mean the upper-case-with-underscores-with-TYPE-in-the-middle version
of the classname?  That sounds like a useful thing to add to the defs
format (for objects, boxed, enums and flags at least).

> 
> The defs format seems to define a great deal of information that does
> not seem needed given Glib's intropspection abilities. For example
> defining the enums, flags, and signals seems like overkill. All of the
> information needed can be queried at runtime. Maybe there is some
> language binding that makes good use of this information?

There is info in the format that I am not using either.  Havoc wrote the
new defs specification while working on his Inti C++ bindings.  I don't
know how much of the stuff in the spec he actually planed on using and how
much he was just guessing would be useful.

I assume that some of the info most interpreted languages would just grab
via introspection may be useful for compiled languages where these things
can't be done at runtime.

> 
> Slightly unrelated: we should also get together to make sure the various
> libraries we want to wrap register things like enums, flags, and boxed
> types with the Glib type system. For example GdkPixbuf doesn't register
> some enums and misc. pointers in Gtk aren't registered.

Gtk 2.0 is actually quite good in this reguard.  The number of uses of
GTK_TYPE_POINTER is down, and getting lower.  If there is any specific
bugs you have found, the gtk+ maintainers would probably appreciate it if
you log them in bugzilla.gnome.org.  Remember to set the 2.0 milestone on
your bug after creating it so it doesn't get forgotten.

James.

-- 
Email: james daa com au
WWW:   http://www.daa.com.au/~james/