A description format for Gtk features
- From: Marius Vollmer <mvo zagadka ping de>
- To: gtk-list redhat com
- Subject: A description format for Gtk features
- Date: 04 Sep 1997 20:09:28 +0200
I'm still busy on the general Gtk high-level language binding issues
and would like to design a file format with which the exported
features of Gtk can be described in great detail.
The individual language bindings would use such a file to automate
most of the glue generation and would thus be able to pick up
additions to Gtk very quickly and confidently.
Idealy, as soon as someone develops a new widget for Gtk or adds some
other stuff to it, he should describe the new features in the special
format. Thus, this file would not only be of interest to the inner
circle of high-level language users, but also to the regular Gtk
Therefore I'd like to know how much extra burden you would tolerate
for the sake of robust high-level bindings.
Would you maintain such a description file? Even if you don't use a
high-level language yourself?
Would it be acceptable if the description file would be the definitive
place for some features (like enums)? That is, if you want to change
the definition of the enumeration, you wuld have to do it in the
Would it be feasible to generate (parts of) the description file from
the C sources?
Would it be feasible to generate some C sources from the description
file? (will not happen during normal install of course)
What precise format should we use for the descriptions?
Not surprisingly, I propose using LISP syntax (just ask if you don't
know what that is). That's what I know and where I am confident that
it can take us wherever we want to go today (tm).
A typical function description could look like:
none ; return type
(GtkTable table) ; first param
(GtkWidget child) ; second
(int left_attach) ; etc.
(GtkAttachOptions xoptions (= (expand fill))) ; default value
(GtkAttachOptions yoptions (= (expand fill)))
(int xpadding (= 0))
(int ypadding (= 0)))
The used types (GtkTable, GtkAttachOption) would have been defined
earlier in the file.
Of course, some form of LISP or Scheme interpreter is the natural
choice for interpreting this format. I don't think we can expect
every Gtk developer to install Guile or some other Scheme. But I hope
that almost everyone will have an Emacs handy. Emacs Lisp is well
suited for this processing. Using Emacs in batch mode is not at all
% time -p emacs -no-init-file --no-site-file --batch --eval '(message "Hi!")'
What about Perl? Can it work with the above syntax? How would a more Perl
rendition look like?
As the last ressort, we could write a simple C program to do the
processing. Maybe we can lift enough code from GCCs RTL processing
tools to make this trivial.
What do you think?
] [Thread Prev