public inbox for
 help / color / mirror / Atom feed
From: James Henstridge <>
To: Miroslav Silovic <>
Subject: Re: Common Gtk/GNOME language bindings?
Date: Fri, 17 Dec 1999 08:11:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

If you are going to make a new binding description format (which I think
is a good idea -- C header files do not convey as much information as is
needed for some bindings), one target should be C headers and skeleton
code.  This way, people who are not even interested in making bindings for
their widget libraries would have a reason to write an description file.

Elliot's extended .defs file format looked like a good starting place for
such a thing.  It would be a good idea to think about what exactly we want
to do with these descriptions.  They may have more use than simple
language bindings.



On Fri, 17 Dec 1999, Miroslav Silovic wrote:

> 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?
> -- 
>         FAQ: Frequently-Asked Questions at
>          To unsubscribe: mail with 
>                        "unsubscribe" as the Subject.

      parent reply	other threads:[~1999-12-17  8:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-12-17  6:24 Miroslav Silovic
1999-12-17  6:52 ` Zach Frey
2000-01-21  9:00   ` Alex Stark
1999-12-17  8:11 ` James Henstridge [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).