Axel Simon <axel.si...@in.tum.de> writes: > Hi Matt, > > On Apr 3, 2010, at 18:45, Matt Arsenault wrote: > >> Hi, >> >> I'm thinking of applying to Google summer of code for Haskell to >> work on >> gtk2hs. I'm thinking of writing a static binding generator based on >> gobject-introspection data. Gobject-introspection is the new way to >> develop bindings for GNOME. > > Yes, I think such a project would be interesting and I would support > your application. Although I think you need a mentor at Google as > well. Maybe you could mail Paolo Martini p.mart...@neuralnoise.com > who had a SoC project when he bound the Cairo modules. > >> I think it could replace most of the current automatic code >> generation, >> and reduce the amount of work that needs to be done by hand. It would >> replace the current ApiGen and associated Perl scripts, and make it >> easier to maintain and produce new bindings to various GNOME libraries >> which aren't currently bound, like telepathy. > > There is only a Perl script that extracts the documentation from the > C sources, thereby producing an XML document. The apiGen tool isn't > all that bad but its front-end is obviously not satisfactory since it > would be better if it would use introspection. > >> I've thought of a few issues with doing this, such as introspection >> not >> having an annotation for whether a function causes a callback for >> finding safe/unsafe functions, but those where it isn't obvious / >> doesn't take a function aren't all that common, but overall I think it >> would be better than the current system. > > apiGen marks every function as safe, thereby ensuring that nothing > goes wrong. It also has quite a few whistles and bells to avoid > generating signals that are definitely not for the end user. I would > welcome it if its framework could be reused. > > One of the annoying issues with changing apiGen is that it does a > clever job of detecting if a function is already present in Gtk2Hs: > > From the XML documentation it calculates a checksum and emits it > into the generated function. The function can now be changed by the > user. As long as the documentation does not change, apiGen will find > that the checksum is the same (even if the function binding was > changed afterwards). Thus, if apiGen changes, all checksums will be > invalid and it will not honor if functions have been manually tweaked. > >> I'm also thinking it might be good to skip the c2hs layer in this new >> tool, avoiding the issues with gtk2hs having to maintain its own old >> c2hs fork vs. the regular version on Hackage. > > As a long term solutions, this is certainly interesting. It is a bit > annoying that many functions that need to be tweaked manually become > harder to write. Yes, i agree this.
It's pain that tweaked manually, it can make your neck hurt long time. :) So you should make your tool smart enough that maintainer don't need write code by hand. Because GObject Introspection do most work, so you just need do a type map from C to Haskell, and make sure every function safe. Then we can focus energy on your project instead gtk2hs. It's will save much much time if you project success. :) Cheers, -- Andy ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
