On Tue, 2004-03-30 at 13:03, Murray Cumming wrote: > On Tue, 2004-03-30 at 19:50, Andreas Rottmann wrote: > > Hi! > > > > [Gauche and Bigloo GTK+ folks CC'ed] > > > > I just finished my first pass through the GTK+ .defs, in preparation > > for making guile-gobject support GNOME 2.6. Due to the huge size of > > the API, this took me most of today afternoon. I think it would be > > definitly worth centralizing the maintainance of these files. > > > > AFAIK, at least pygtk and guile-gobject use those files. James, how do > > you feel about maintaining these cooperativly? In the near future > > (with some luck in the next two weeks) the current guile-gobject > > "monolith" project will be split up into several pieces, managed in > > different Arch[0] packages. I think it would be a good idea to have a > > seperate "defs" package, containing only the .defs files for all > > (well, all that we already have .defs files for) GNOME APIs. There > > will be branches for each released GNOME version (starting with 2.6). > > If we do this, let's have the defs in GNOME's cvs. I guess we could have > a gnome-defs module, with sub-directories for each GNOME module, such as > gtk+, atk, libgnomeui, etc. I think we'd actually open to include .defs with the modules themselves; the downside being, of course, that you don't get updated defs until the module releases a new version. The other downside is that it is easy for the GTK+ version to get out of date if people aren't careful about putting back their changes to the canonical version ... I'm actually pretty interested in exploring the question including full method introspection in the binary libraries as discussed recently; if we could generate that from header file / magic comment parsing and not have .defs files at all, I think that would be great. It's probably over-optimistic to target that for GTK+-2.6 cycle, but it certainly wouldn't hurt to start looking at it. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part