Common Gtk/GNOME language bindings?

Common Gtk/GNOME language bindings?

[Miroslav Silovic]

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?

Re: Common Gtk/GNOME language bindings?

[Zach Frey]

On Fri, Dec 17, 1999 at 03:06:28PM +0100, Miroslav Silovic wrote:
> 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.

 
Well, there's always SWIG < http://www.swig.org/ >, which already
provides a format for a binding hints file (if one doesn't like what
SWIG comes up with as default bindings), and glue/stub code generation.

Supported languages include Perl, Python, Tcl, Java, Eiffel, and 
even Guile.

So maybe it would make sense to see if SWIG does what is desired
before reinventing any wheels.


FYI,

Zach

-- 
Remember, you're a software professional, not a magician.  Leave the
illusions to management.
  -- Dinu Madau

Re: Common Gtk/GNOME language bindings?

[James Henstridge]

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

Re: Common Gtk/GNOME language bindings?

[Alex Stark]

My 2c worth is that provision for very short documentation strings (ie
fewer than 60 chars) could be very useful.

As part of writing the tutorial examples, I found it pretty easy to
convert the defs files into human-friendly catalogues, and the really
neat thing with using guile-gtk is that it is simple to use
gtk-object-query-args to expand the information in the defs files.  One
could even validate features and procedures quite extensively.

IMHO, it is potentially of enormous benefit to be able to generate a
catalogue of features which is up-to-date.  (I have just wasted a lot of
time doing something trivial with RedHat rpms where the documentation is
confident but misleading, conflicting and obselete.)

Alex.