Re: Bug #679291 (please review)

[John Lindgren <john lindgren aol com>]

On 08/04/2012 05:54 PM, Matthias Clasen wrote:
> On Sat, Aug 4, 2012 at 4:58 PM, Emmanuele Bassi <ebassi gmail com> wrote:
> 
>> the patch in attachment 217892 looks okay - but what I'd like to see:
>>
>> a) bisecting to see what commit broke this;
>> b) a test case for the TreeView test suite, to ensure we don't regress again;
>> c) a patch done using git format-patch or git bz, so that we can credit the
>> author.
> 
> The behaviour change was introduced during the heavy refactoring of
> treeview a11y done by Benjamin last winter. We've talked about
> 'fixing' this (ie suppressing the signal in the destroy path), but
> there's a more general question here: do we want to add tons of
> special-cases to prevent this kind of noise in destroy paths ? There's
> plenty of other places where this could happen.

What do you suggest as an alternative?  I don't think it's reasonable to
require every GTK+ client to disconnect every signal handler from every
object before it is destroyed, in fear of the handler being called from
the destroy path, when the internal state of the object is more or less
undefined.

How about disconnecting all signal handlers on the GTK+ side immediately
after emitting the "destroy" signal?  It seems reasonable to me that no
signal should ever be emitted after "destroy", but I could be
overlooking something.

-- John