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 <mhenrion@...> 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

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 <mhenrion@...> 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