From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Browning To: Marius Vollmer Cc: Ariel Rios , guile-gtk@sourceware.cygnus.com, Miroslav silovic Subject: Re: g-wrap and guile-gnome/gtk Date: Sun, 12 Nov 2000 09:02:00 -0000 Message-id: <87lmupf7je.fsf@raven.localnet> References: <20001111173022.14524.qmail@nwcst322.netaddress.usa.net> <87lmuqnud4.fsf@zagadka.ping.de> X-SW-Source: 2000-q4/msg00017.html Marius Vollmer 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 PGP=E80E0D04F521A094 532B97F5D64E3930