Re: [gtk-list] newbie question on gdk

[Vollmer Marius <mvo zagadka ping de>]

Michael Beach <mbeach@zip.com.au> writes:

> I was going to look at the Guile/Gtk bindings next.

Ok, great!
 
> > Maybe you can use some of the code, or ideas, for your RScheme
> > bindings.  But it would super cool if we could merge Guile and RScheme
> > support somehow.  Maybe this can give some boost the the gh_ interface
> > of Guile, which has been rumored to be available for RScheme also, I
> > think.
> 
> gh_ support is pretty cursory afaik in RScheme at the moment; "proof of
> concept" I believe is the term used in the source comments. But I
> certainly agree; merging the Guile and RScheme support would be a
> definite win.

Yes, and by doing so, we would have to use the gh_ stuff for real and
exclusively.  This should help to make it really useful, if it isn't
already.
 
> Further to this, and since you bring up the whole issue, I have a couple
> of questions about gtk and the Scheme support so far:
> 
> [1] I recall reading somewhere about a gtk.defs (I think I got that name
> right) file, for providing defns for gtk types etc that is language
> independent. Is this a mainstream part of gtk, ie part of the main
> distrib?

Yes, eventually, it should end up being a part of gtk+ and being
installed along with the rest of gtk.  But right now, the canonical
version is in the guile-gtk dir of GNOME and I only occasionally have
synched the gtk+/gtk/ version with it.  When it sees more widespread
use, we should definitely strive to make the one in gtk+ be canonical.

> Is it autogenerated from gtk.h et al or is it maintained by
> hand?

It is maintained by hand.  I don't think that the C rendition of the
gtk interface carries enough information.  We would have to stick some
info in specially constructed comments, or something.  Pretty unclean,
IMO.  Anyway it is really no big deal to update it.

> How about generating gtk.h from it, or vice versa?

Hmm, it would certainly be nice to have only a signle source for the
features described in gtk.defs.  But just as C does not reveal all
necessary information for gtk.defs, gtk.defs does not contain enough
details for generating gtk.h from it.  I think we are best off by
treating gtk.defs as a non-essential add-on to gtk+.

> Have you seen SWIG? Do you think it could be useful here?

Yes, I have seen SWIG but only very superficially.  Its duty is done
by gen-typeinfo.  Gen-typeinfo is not all large or complicated and it
does exactly what I want.  Using SWIG would give as automatic bindings
to a number of additional languages, right?  That would be cool, but I
have not enough experience to see whether this would really work.
There are some special things in the gtk+ interface (like GtkObjects)
that are maybey hard to treat cleanly with a general tool like SWIG.

> [2] The gtk reference counting stuff. I've seen bits of that in the
> distrib. Is that up and happening, and getting everyday use, or is
> it still on its way and a bit experimental?

I think we have crossed the point-of-no-return, thanks to Owen and
Tim.  As far as I know, the Gimp does already work with the new stuff,
right?

> Is it meant to be particularly related to Scheme (and other dynamic
> language) interfaces, or do you see it as being pretty much
> orthogonal.

It was first motivated to get bullet-proof memory management for
dynamic languages, mostly from a Guile perspective.  But the revised
ref_counting is also necessary to have the tools for fixing a number
of tricky bugs in gtk itself, I think.

So the implementation is not especially geared towards dynamic
languages.

> [3] I read somewhere that you (I think?) had a proposal for
> redesigning the gtk type system. Again, is this related to Scheme,
> or is it orthogonal.

This is more related to dynamic languages, to allow them to do
stricter type checking at run-time.  It was also meant for formalizing
the existing practice and thus making the bigger part of gtk+ be
wrappable by some highly automated means, like gen-typeinfo.  I think
it is pretty much in place now.  There might be some extensions coming
for in/out arguments, tho.