Hi Andy, On Apr 21, 2010, at 17:58, Andy Stewart wrote:
> Hi Axel, > > Axel Simon <axel.si...@in.tum.de> writes: > >> Observe that updating your current darcs repo of the previous version >> of Gtk2Hs is not possible since I had to obliterate several patches >> in >> order to merge changes. Furthermore, there are quite a few patches in >> the previous repository that added a lot of new functions but which >> need further review. These patches have been merged into the new >> cabal >> version but for now remain in a separate repository which can be >> accessed at http://www2.in.tum.de/~simona/gtk2hs-2.18 . > For current situation, we have two jobs need to do: > > (1) http://code.haskell.org/gtk2hs/ > Convert all packages to Cabal and build new repositories. > > (2) http://www2.in.tum.de/~simona/gtk2hs-2.18 > Review code and push new patches to fix bugs. > > http://www2.in.tum.de/~simona/gtk2hs-2.18 including all patches i > push? Yes, pretty much. I've not applied patches relating to Pango since these would have seriously broken what I have done. I can probably add the new files but this has to be done in an informed way. Both, pango and glib have a lot of functions that are either not useful to the end user or really awkward to bind (i.e. unicode indices vs byte indices in Pango). > Cabal Setup script looks can't generate Types.chi correct, so i can't > convert non-core packages until you fix it. In my last email I said: "Make sure that Graphics.UI.Gtk.Vte.Types *is* listed in the module list of the cabal file." I think you misread this. > So i'm try to fix bugs in http://www2.in.tum.de/~simona/gtk2hs-2.18, > have you any notes or *fix list* need to share? I don't have a list. But from the top of my head I know that you bound gdk_pixbuf_loader_get_format which returns a pointer to some internal data. This pointer cannot be copied, nor can it be freed. The only safe way to deal with it is to take the pointer and extract all information from it (using the gtk_pixbuf_format_xxx functions) and returns these values in a Haskell (record) data type. You need to define (and document) such a data type and then return this data type from the pixbufLoaderGetFormat function. Keeping the pointer around is not safe since it will be invalid as soon as the PixbufLoader goes out of scope. In fact, you would have to apply touchForeignPtr after you extracted all the information from the GtkPixbufFormat pointer to make suer that the PixbufLoader is not garbage collected before you have extracted all the information! Rather than going for these complicated functions, you could just add methods and signals to the various objects. Please make sure that you don't bind signals that are used internally by the widget. These are key-binding signals and anything that sounds like an action the widget can perform (i.e. something like combo-box-drop-down). The user cannot send these signals (there are usually methods to perform these actions) and connecting to them is also meaningless. Keeping Gtk2Hs free of these signals and other methods will keep it usable to the end user. You've already done good work on some of the functions were you added an Attribute and marked the get* and set* method as deprecated. That is a right step to make Gtk2Hs simpler. Check your signal names: Sometimes apiGen uses an underscore in names (_) rather than a hyphen (-). If in doubt, look into the .c file of the corresponding widget. Cheers, Axel. ------------------------------------------------------------------------------ _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
