Hi Axel, On Fri, 2010-11-26 at 08:55 +0100, Axel Simon wrote: > Hi Maxime, Andy, > > On Nov 25, 2010, at 19:44, Maxime Henrion wrote: > > > Hi there! > > > > Sorry for the very late reply; I got caught up in that thing called > > "real life"... :-) > > > > On Tue, 2010-10-26 at 10:07 +0800, Andy Stewart wrote: > >> Hi Maxime, > >> Maxime Henrion <mhenr...@gmail.com> writes: > >> > >>> Hello all, > >>> > >>> > >>> Yet another not really interesting patch :-). It provides a new- > >>> style > >>> signal handler for the "destroy" signal of the Widget object (not > >>> the > >>> same as the "destroy-event" one). > >> I guess you want patch for module Gtk/Abstract/Object.chs ;) > >> > >> We have signal 'objectDestroy' in Object.chs > >> > >> Anyway, thanks for patch! :) > > > > Yup, I had seen 'objectDestroy' in Object.chs, thanks to the link > > provided in the documentation for the "destroy-event" signal. My > > problem with that is that this signal handler is not at the same level > > in the object hierarchy than the one in GTK+. I find this > > unintuitive, > > and it is bound to confuse users of our bindings at some point. I > > think > > we should aim at minimizing such differences, which is why I proposed > > that patch. > > > > Is there a legitimate reason for this difference? > > > > From the top of my head: there is a destroy event and a destroy > signal, both are quite different: the first closes a window (or not, > depending if you want it to) and the second is called before the > memory of an object is freed.
That indeed corresponds to the state of gtk2hs, where we have 'destroyEvent' in Widget, and 'objectDestroy' in Object. I was about to say that this doesn't match GTK+ however, and I've been looking up the API documentation to provide links backing my claims. It turns out that I must not be able to read the API documentation properly, because I can only find the "destroy-event" signal documented in GtkWidget, and the "destroy" one is indeed documented in GtkObject. My whole reasoning is thus completely moot... In short, I'm an idiot, and I'm sorry for wasting both your and Andy's time. :-) > The first must be in widget, the second must be in object. We could > have a signal with the same name in widget as well (and the destroy > signal might have been in widget at one point in the past). Wouldn't > that be even more confusing? I've tried to point this out in the > documentation: maybe we should improve that further. > > >>> There's one nit though: the documentation for other signal handlers > >>> include tags such as "%hash c:c408 d:5514". I suppose this points > >>> to > >>> the external GTK+ documentation somehow, but I have no idea how to > >>> get > >>> one for this signal handler. So I just provided the documentation > >>> text > >>> from the upstream documentation. > > > > If you're using apiGen, then it will calculate a hash from the C > function signature and the documentation. You can then modify any > function that apiGen generates and, as long as the original C function > and documentation has not changed, apiGen simply retain that function. > (It produces a new module in which new functions are added and > unchanged functions are copied in from the existing module). > > Cheers, > Axel ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
