Re: Good OO Bindings for Gtk+

[otaylor redhat com]

Eric Kidd <eric.kidd@pobox.com> writes:

> OK, several people seem interested in having good Gtk+ bindings for their
> faviorite object-oriented language. I can help with this in a big way if
> people tell me what they need.
> 
> What I've got:
> 
>  * A C parser. It handles almost any Unix header without changes. This is
>    based on some code from CMU's Gwydion Project which I've been enhancing.
>    I've tested it extensively against the Gtk+ 1.2 and Gnome 1.0 headers.
>  * A C preprocessor. It co-operates with the C parser to return information
>    about #define's and #include's.
>  * A copy of K&R second edition.
> 
> All of my tools are free software and will be part of the GNU project. I'd
> like to enhance them to read gtk/gtk.h and output a high-level,
> easy-to-parse description of the objects and functions defined in the Gtk+
> headers.

Note that there has been some work on this already, though
it isn't totally satisfactory or complete.

The gtk.defs file in the GTK+ distribution is the current
"standard format". It lists:

 Enumeration definitions
 Flag (bit-field) definitions
 Some information on memory-management for "boxed" types -
  (opaque types that are not GTK+ objects)
 Functions (not nearly complete)

It does not cover signals or object arguments (both of which,
can, in theory be queried from a running GTK+ library)

Both guile-gtk and Perl/Gtk use somewhat extended/modified
version of this file.

Portions of this file are hand-edited, but the enumeration
definitions are scanned from the header files by a perl
script. (makeenums.pl)

As part of this, there is a standard syntax for embedding
additional annotations in the GTK+ header files.

 /*< KEY=VALUE [, KEY=VALUE...] >*/

For instance:

===
typedef enum {
  GTK_TARGET_SAME_APP = 1 << 0,    /*< nick=same-app >*/
  GTK_TARGET_SAME_WIDGET = 1 << 1  /*< nick=same-widget >*/
} GtkTargetFlags;
===

There has also been some interest in extended CORBA-IDL
to be able to cover the GTK+ type system; which would be
nice, though it would require a more heavyweight tool
to parse, and there are a number of sticky areas in
the mapping between the two.

I have a vague memory that someone else wrote some
header-scanning tools for another language binding - 
though I might be remember an earlier message from
you ;-)

> Here's what I guess I need to know:
> 
>  * What language do you create bindings for?
>  * What tools do you use now? Can I see their input and output formats
>    online?
>  * Would you have any use for a high-level description of all the objects
>    and functions in the Gtk+ headers?
> 
> I can get something working over a long weekend, and I need to be looking
> at these problems anyway. Oh, yeah--the tools are written in my favorite OO
> language, so not everyone's going to want to build them from source. They
> can, however, be compiled using various GNU tools, and not that many people
> would need to run them. I can also provide x86 binaries.

Hmmm,

I don't want to the throw cold-water on your project,
but this is a fairly serious problem. Basically, any tools
used for GTK+ need to be compileable from source and useable
without jumping through too many hoops. Currently, the
only languages used for the GTK+ tools are Perl, C, and
awk.

Regards,
                                        Owen