[798] in The GTK GIMP ToolKit mailing list archive

home help back first fref pref prev next nref lref last post

[gtk-list] Re: Gtk and the scripting languages of the world

daemon@ATHENA.MIT.EDU (Marius Vollmer)
Fri Aug 22 08:49:02 1997

To: gtk-list@redhat.com
From: Marius Vollmer <mvo@zagadka.ping.de>
Date: 22 Aug 1997 11:50:20 +0200
In-Reply-To: atai@ece.ucsd.edu's message of Thu, 21 Aug 1997 18:48:23 -0700 (PDT)
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com

atai@ece.ucsd.edu (Andy Tai) writes:
> 
> Please whatever you do, remember that there are lots of programmers
> who prefer to use C/C++ over any script languages for building GUI
> and large scale projects.  So your interface should not degrade the
> gtk's utility for low level programming and make it difficult for
> building advanced C++ toolkits on top of gtk.

Yes, I try to be careful.  As Peter Mattis pointed out, there is
already some non-trivial amount of code out there that uses Gtk.  I
don't want to break it, of course.  Likewise, I don't want to take
features away from Gtk only because I don't know how to interface them
to Scheme.

I'm, however, of the opinion that we have to take the needs of
higher-level languages into account when designing the Gtk API.

You just need some working form of automatic garbage collection when
writing large, long-running, interactive programs.  You need powerful
abstraction tools for prototyping and implementing new interfaces.  I
can't get that easily from C or C++.

But I do recognize the importance of a reasonable C API to Gtk.  I'm
just not enthusiastic about it.
 
> We do not want gtk to become another Tk.

The major problem of Tk is its strong dependence on TCL.  It cannot
live without TCL.

Gtk should be usable from C and C++, but also from Perl, Phython and
Scheme (and any other inetersting languages, maybe Common Lisp).
These interfaces to the high-level languages should feel `natural' and
be robust.  It should be easy to evovle them alongside an evolving Gtk
and they should be able to easily cover `third party' extensions to
Gtk.

--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null


home help back first fref pref prev next nref lref last post