first off, I think it's great if people are looking into using
introspection to get Gtk2Hs up to date again.
On 31.01.2013, at 10:55, Luca Bruno wrote:
> Is the plan to use haskell-gi to replace most of the gtk2hs
> package/repo (or will there be a whole new gtk3hs package/repo)? If
> the changes will be in the gtk2hs package/repo, will adding these Gtk3
> patches as well make it harder to port to GI? (If so we might need to
> have a temporary fork gtk2hs-gtk3 or gtk2hs-leksah in Hackage so we
> can get the Gtk3 fixes into Leksah).
> As far as I know, the gtk2 annotations are not very good, I would
> discard it. For what concerns gtk3, haskell-gi generates a Gtk3.hs,
> so I think that would be a completely different repo. For pygobject
> typelib at runtime.
The docs are sometimes off in Gtk2Hs but a lot of the stuff is also a
bit different and Haskellized. It would be shame to lose that.
> In general, this is how it should work:
> 1) haskell-gi reads the typelib or gir (currently the typelib) for a
> 2) It reads an additional metadata/override file for possible custom
> functions or fixes. This is not done yet in haskell-gi, but it's
> done in other languages, seehttp://git.gnome.org/browse/pygobject/tree/gi/overrides
> and http://git.gnome.org/browse/vala/tree/vapi/metadata
> 3) Merge the two and produce the bindings Foo.hs ready to be
> compiled and used.
Duncan once made a binding tool that tried to parse in the
current .chs files and then added new bindings that weren't already
defined. That way, he managed to mix the the metadata/override file
with the result. The way it worked was that the tool would generate
the source for a function in memory, compute a hash value and if, the
function wasn't defined in the .chs module yet, it would add it,
including the hash value.
The function can then be changed by hand. If the tool sees this
modified function with the same hash code that it computed for the
generated version, it leaves the function alone. Only if the function
changes in Gtk3 (and thus the hash code is new), the new version
replaces the old.
The code for doing this is already in the Gtk2Hs repository. In case
you feel comfortable with this concept, you would have a starting point.
One thing that often has evaded the automatic generation is memory
management. Most functions obey a convention in that a _new function
returns a pointer on which sink() without ref() has to be called (or
similar) while other functions that return objects must be wrapped
with a function that does a ref(). Sometimes this is different
(especially some functions take over ownership of an object, in which
case ref() has be called before the object is passed to the function).
I hope this is all conveyed in the introspection data.