From: Maxime H. <mhe...@gm...> - 2010-10-25 23:05:19
Attachments:
gtk2hs.patch
|
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). 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. Cheers, Maxime |
From: Andy S. <laz...@gm...> - 2010-10-26 03:05:22
|
Hi Maxime, Maxime Henrion <mhe...@gm...> 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! :) > > 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. BTW, if you use Emacs, you can use my gtk2hs extension: http://www.emacswiki.org/emacs/gtk2hs.el Open GTK+ manual in Emacs-w3m, select documentation and do 'gtk2hs-format-docs' Cheers, -- Andy |
From: Maxime H. <mhe...@gm...> - 2010-11-25 18:44:13
|
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 <mhe...@gm...> 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? > > 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. > BTW, if you use Emacs, you can use my gtk2hs extension: > http://www.emacswiki.org/emacs/gtk2hs.el > > Open GTK+ manual in Emacs-w3m, select documentation and do 'gtk2hs-format-docs' Unfortunately, I'm not using emacs, and I have no intention to switch to another editor :-). Is there another way to get to those tags? Or can I just ignore this issue and leave it to others to deal with in the future? Cheers, Maxime |
From: Axel S. <Axe...@in...> - 2010-10-26 08:18:59
|
On 26.10.2010, at 01:05, Maxime Henrion wrote: > 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). > Yes, as Andy says, this handler is actually part of Object. > 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. > Please just retain these tags. They are used by the code generator tool. It calculates a hash from the C code: if the C code has not changed, it will not suggest that this function is replaced by a new version, even if we edit the Haskell code. Cheers, Axel |
From: Andy S. <laz...@gm...> - 2010-11-25 19:03:38
|
Maxime Henrion <mhe...@gm...> writes: > 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 <mhe...@gm...> 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? I don't know the reason, but best don't change those since it will break user's code. :) > >> > 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. >> BTW, if you use Emacs, you can use my gtk2hs extension: >> http://www.emacswiki.org/emacs/gtk2hs.el >> >> Open GTK+ manual in Emacs-w3m, select documentation and do 'gtk2hs-format-docs' > > Unfortunately, I'm not using emacs, and I have no intention to switch to > another editor :-). Is there another way to get to those tags? Or can > I just ignore this issue and leave it to others to deal with in the > future? There have ApiGen in package 'gtk2hs-buildtools', but that need XML and Mono something... You can ask if you interested ApiGen, Axel will answer it. Cheers, -- Andy |
From: Maxime H. <mhe...@gm...> - 2010-11-25 19:09:37
|
On Fri, 2010-11-26 at 03:03 +0800, Andy Stewart wrote: > Maxime Henrion <mhe...@gm...> writes: > > > 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 <mhe...@gm...> 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? > I don't know the reason, but best don't change those since it will break > user's code. :) I don't see how it would break anything; the handler in Object.chs is named 'objectDestroy' and the patch I sent provides a 'destroy' signal handler. I wasn't suggesting to remove the 'objectDestroy' one. > >> > 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. > >> BTW, if you use Emacs, you can use my gtk2hs extension: > >> http://www.emacswiki.org/emacs/gtk2hs.el > >> > >> Open GTK+ manual in Emacs-w3m, select documentation and do 'gtk2hs-format-docs' > > > > Unfortunately, I'm not using emacs, and I have no intention to switch to > > another editor :-). Is there another way to get to those tags? Or can > > I just ignore this issue and leave it to others to deal with in the > > future? > There have ApiGen in package 'gtk2hs-buildtools', but that need XML and > Mono something... > > You can ask if you interested ApiGen, Axel will answer it. Thanks. Maxime |
From: Axel S. <Axe...@in...> - 2010-11-26 07:56:16
|
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 <mhe...@gm...> 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. 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 |
From: Maxime H. <mhe...@gm...> - 2010-11-26 17:20:34
|
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 <mhe...@gm...> 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 |