On 2/13/07, Andre Kuehne <[EMAIL PROTECTED]> 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. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users