Hi all,

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  
> and javascript there's no separate repo, because they load the  
> 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  
> library.
> 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.

Cheers,
Axel

>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gtk2hs-devel mailing list
Gtk2hs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel

Reply via email to