Re: g-wrap and guile-gnome/gtk

[Rob Browning <rlb at cs dot utexas dot edu>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> If I remember correctly, build-guile-gtk is actually derived from a
> early version of g-wrap.  I quickly decided to `roll my own' because
> that was easy to do and I didn't know what I wanted precisely.

Ahh.  That makes sense.

> Build-guile-gtk is still a one-off hack and needs to be redone
> completely to make it reasonably clean.  This includes the syntax of
> the defs files themselves, but hopefully we can clean that up in a
> backward compatible way because they are already defs files out there
> that are distributed independently from guile-gtk.

Well, since everything's just scheme forms, and since the .defs files
aren't even allowed to be general scheme syntax, this should be easy.
We could probably even just write a translator script that was nothing
more than a set of guile macros that rewrote and "displayed" their
contents as g-wrap specs.

> Working towards g-wrap would be the right thing, this time.

Well, I want to make it clear that I'm not hung up on g-wrap as it is.
If we need to change things, or even if we decide that we need to work
on some other common effort, it sounds to me like a joint solution
would benefit everyone.

Also, g-wrap's pretty good, but I think it could use some cleaning up.
I need to rewrite some of the internals to be clearer now Christopher
Lee and I have agreed that guile will be the only implementation
language (not the only target language).  In the past g-wrap was
implemented in both rscheme and guile, and that required some
complexities that are now irrelevant...

> Because g-wrap def files are just Scheme code, I think we should start
> by trying to write implementations for define-object, define-func etc
> in terms of the normal g-wrap features.  A *.defs file could then
> start like this
> 
>     (use-modules (gtk g-wrap-defs))
> 
>     (define-object GtkObject
>       (fields ...))
> 
> or build-guile-gtk could be a thin wrapper that invokes g-wrap in the
> right way.
> 
> Does that make sense?

Perfect sense.  One thing we might want to decide is if it's OK that
the API spec files are just scheme code.  G-wrap handles it that way
right now, but that could be changed.  Allowing arbitrary scheme code
does have its advantages since it's really easy to do things like
conditional inclusion, and other things you haven't thought of, and so
I tend to favor it, but it also has its weaknesses (like making it
harder to spot and flag syntax errors), so I'd certainly be willing to
consider the issue.

Also, it might be easier to maintain in the long run to just create a
simple .defs -> .gwp translator script than to support two syntaxes in
the front end.  This might be a good approach across the board.  Who
knows, one day we might even be able to "steal" specs from other
places by creating other translators.

Also, I think that as soon as I finish incorporating Robert Merkel's
new patch, which adds C enum support to g-wrap, g-wrap may be a
functional superset of what the .defs can do, though I'm not
absolutely sure of that.  I know that the way he handles enums is more
flexible, if a little more complex (for example, we designed it so
that you can use enums as either symbols or integers from the Scheme
side).  I should be finished incorporating that patch in a day or so.

Also, if all goes well, I might even be able to get the dlopen loading
working by then, so whta you'd be able to say things like:

  (use-modules (gwp opengl))
  (use-modules (gwp curses))

and have the thing you think would be cool to have happen, actually
happen :>  We'll see...

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930