chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] gtk2.egg


From: Tony Sidaway
Subject: Re: [Chicken-users] gtk2.egg
Date: Wed, 14 Feb 2007 15:45:07 +0000

On 2/13/07, Andre Kuehne <address@hidden> wrote:
Tony Sidaway wrote:
[...]

> The main part of the code is a pretty straightforward wrap of libgtk2
> and libglade.  The only unusual thing is that a bespoke wrap program
> is used instead of SWIG, and relies on "defs" files that are published
> by the (Python) PyGTK project.
>
I have no experience with writing glue-code, just curious. What's the
advantage over SWIG? Does this approach make it easier to stay compatible
with new gtk versions, since PyGTK is guaranteed to be?

SWIG is excellent, but it's an automated tool and has limitations.

For instance SWIG is unlikely to be able to reconstruct the object
structure of the library components because the code is C and the
underlying object definitions are partly a matter of coding convention
and partly due to GTK+'s runtime object support system, gobject, of
which SWIG understandably knows nothing.

I inherited the wrapping code from Tony G, and he seems to have done
an excellent job of capturing the object semantics, partly because
they are encapsulated in the PyGTK definitions which are used to guide
the wrapping process.

By the way I'd forgotten that there is actually a very good manual to
this egg in the doc directory.

I've decided to split off the gobject part of the library, and the
glade part, each into its own egg.  The Glade code doesn't have any
dependencies on the gtk binding, so it's perfectly possible to have a
working Glade application in Chicken with only the gobject egg and the
glade egg.  Glade also has a lot of potential in Scheme because its
object model is XML, and Scheme + sxml + Glade would probably make a
very good GUI scripting toolkit.  Other candidates for splitting off
are gdkevent (low level event support) and gdk itself (drawing kit).

There is also the possibility of splitting the GTK code into basic.
intermediate and advanced modules.  I'd have to satisfy myself that
basic and intermediate modules would be useful for producing real
code, but there is also an impetus here to make the huge wodge of code
more manageable, as well as reducing installation time.  The gobject
code, for instance, takes a few seconds to install on my system, and I
would like to produce a basic install for gtk that took a comparable
amount of time, so that the programmer evaluating this egg could
download and run example code casually before committing himsel to a
long egg install to get at the juicy stuff needed to produce advanced
Scheme GUI code.

>
Attached is a drop-in-replacement for "extract-all-types".

Thanks.  I've been away from the net for a couple of days and I also
wrote a replacement in Chicken.


Additionally the script excludes "gdk_window_get_type".
Otherwise i get this compile error:

I think I need to work on the wrapping. The egg should perhaps contain
a master file containing information merged from all defs files, with
information about how the functions have evolved. Only those
definitions pertaining to the GTK version we're building for should be
selected during a particular build.

In my working copy I've hand-coded some of the NULL-sentinel varargs
functions, but wrap.scm should be fixed to take care of this itself.
The functions in question are well flagged in the header files (at
least for recent versions) although not in the defs files.

>
Besides the error mentioned above, it compiles against my gtk+ 2.10.6.

However most sample-apps crash:

Yes, it's early days.  It's good news that it seems to be close to
working on recent releases of GTK, but we have to live with the fact
that many installed Gnome systems are built on top of GTK releases
that are somewhat behind the cutting edge, and I myself would hesitate
to rebuild the foundation of my Gnome system's GUI, lest something
break and I end up with no GUI for a while.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]