public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Miroslav Silovic <silovic@zesoi.fer.hr>
To: jarios@usa.net, hp@redhat.com, otaylor@redhat.com,
	james@daa.com.au, sopwith@redhat.com, federico@redhat.com,
	guile-gtk@sourceware.cygnus.com, gnome-list@gnome.org
Subject: Common Gtk/GNOME language bindings?
Date: Fri, 17 Dec 1999 06:24:00 -0000	[thread overview]
Message-ID: <199912171406.PAA23091@petra.zesoi.fer.hr.> (raw)

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?

             reply	other threads:[~1999-12-17  6:24 UTC|newest]

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

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=199912171406.PAA23091@petra.zesoi.fer.hr. \
    --to=silovic@zesoi.fer.hr \
    --cc=federico@redhat.com \
    --cc=gnome-list@gnome.org \
    --cc=guile-gtk@sourceware.cygnus.com \
    --cc=hp@redhat.com \
    --cc=james@daa.com.au \
    --cc=jarios@usa.net \
    --cc=otaylor@redhat.com \
    --cc=sopwith@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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