On 27/10/11 19:52, Axel Simon wrote: > Hi Andrew, > > On 27.10.2011, at 05:50, Andrew Miller wrote: > >> On 27/10/11 12:52, Andrew Miller wrote: >>> Hi all, >>> >>> I'm working on bindings for libappindicator (see >>> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators and >>> http://developer.ubuntu.com/api/ubuntu-11.10/c/appindicator/libappindicator-app-indicator.html). >>> >>> >>> >>> My bindings use the same build system as gtk2hs. >>> >>> Would it be appropriate to set the maintainer of the package as this >>> list? >> > > Hm, if you promise that you stay subscribed then I don't see a problem > in using this list. However, the maintainer is really you and the fact > that we use the mailing list as the contact for all the various > Gtk2Hs-dependent packages is a legacy. So I guess it's up to you. Is > there at least an author field that haddock can print? I think not...
Cabal has an Author: field, which is displayed on Hackage's project pages (but not Haddock output). I've changed it to include an e-mail as well, so it now reads: "Author: Andrew Miller <and...@amxl.com>; some parts derived from Gtk2hs by Axel Simon, Duncan Coutts and many others" I've also added Maintainer: gtk2hs-devel@lists.sourceforge.net I'm happy to stay on the list; I think that having a list as the maintainer is good practice, because if someone stops responding for whatever reason, the people most likely to be able to take over are aware of any patches / bug reports (from personal experience, I've found the 'missing maintainer' problem is already quite common, and it is only going to become more common as packages get older). > >> Just to follow up on this, the source code is now up on github: >> * https://github.com/A1kmm/happindicator >> >> I've uploaded version 0.0.1 of the package (with no Maintainer: field in >> the package description yet) to: >> * http://hackage.haskell.org/package/happindicator >> >> I created a simple example program in the demos directory, but it would >> be good to have more tests. >> >> This is my first gtk2hs-style binding, and so any feedback or criticism >> would be welcomed, especially if I've inadvertently done something in a >> non-idiomatic way. > > I think there is a memory-management issue: > > -- | This function retrieves the Application Indicator menu. > appIndicatorGetMenu :: AppIndicatorClass self => self -> IO Menu > appIndicatorGetMenu self = > wrapNewGObject mkMenu $ {# call app_indicator_get_menu #} > (toAppIndicator self) > > Here, you probably need to use makeNewGObject which will add a reference > count: you extract the handle to an object that stays inside the self > object. Thus, in order to ensure that the Menu survives the > AppIndicator, you need to add a new reference which is what > makeNewGObject does. wrapNewGObject, in contrast, will free the object > but not ref it. It's only used when you call a function that constructs > a new object since that has a reference count of 0 (well, thereabouts, > it's called floating reference). Thanks for this; I've fixed this issue in happindicator-0.0.3 (which also adds some missing documentation, and adds my e-mail to the author field and the maintainer field to the package description). Best wishes, Andrew ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
