This is the mail archive of the guile-gtk@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Common Gtk/GNOME language bindings?



While both Gtk and the various GNOME libs are very easy to bind to any
language, the sheer number of the libraries I'd want to see bound to
get the same features as C is frightening (Gtk/gdk, gnome-libs,
libxml, libghttp, libgtop, libglade, libbonobo, libvfs (when it
arrives) - that's what I could count from top of my head) and seems to
be growing as GNOME matures. So, after some discussion on IRC and
guile-gtk, here's the proposal for unified specification for language
bindings.

First, to bind the language with GNOME, you need 3 things: glue code
to talk to Gtk framework and handle datastructs that typically come
with GNOME calls, specification file compiler, and a bunch of
specification files that specify various APIs in detail. The latter
can't be achieved by parsing C headers, for example, because C headers
don't cover *meaning* of some parameters, for example: foo (bar *data,
int ndata) should just take an array in Python, Perl, Guile, or TOM. I
think that specification files can be shared, once we reach some
intelligent way of speccing things that would work for different
languages (precedent: rep, the LISP used in Sawmill, uses guile-gtk
specfiles). CORBA IDL doesn't fill this bill (because IDL->C binding
is one way and I don't think GNOME libs follow it).

So, here is my suggestion:

 - decide on the common file format

 - write the spec files (large part of this can be achieved by
   converting guile-gtk files, or specfiles from some other project)

 - write the glue and stub generator for the target languages.

The advantage of this approach is that writing (and, more importantly, 
maintaining) specfiles can be shared between -all- the language
binding projects. I'd like to work on the code side of the things,
after the specfile format is hashed out.

-- 
How to eff the ineffable?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]