Re: Common Gtk/GNOME language bindings?
- From: James Henstridge <james daa com au>
- To: Miroslav Silovic <silovic zesoi fer hr>
- cc: jarios usa net, hp redhat com, otaylor redhat com, sopwith redhat com, federico redhat com, guile-gtk sourceware cygnus com, gnome-list gnome org
- Subject: Re: Common Gtk/GNOME language bindings?
- Date: Sat, 18 Dec 1999 00:12:50 +0800 (WST)
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.
James.
--
Email: james@daa.com.au
WWW: http://www.daa.com.au/~james/
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 http://www.gnome.org/gnomefaq
> To unsubscribe: mail gnome-list-request@gnome.org with
> "unsubscribe" as the Subject.
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]