Re: [evolution-patches] Evolution fix for #307794

[Not Zed <notzed ximian com>]

Hmm, no c++ comments, its right in theHACKING file.  Go re-read it
again.

Anyway, no, you definitly can't do this, they have to be destroyed or it
will just break the whole e-config model.

Can you just add an idle handler so the server-changed event doesn't
directly trigger the rebuild?  Maybe you can just do it in the
target_changed code in e-config, so it doesn't have to be done in all
the cases a rebuild is called for.  It might cause other issues though,
and make sure the idle handler is removed if the object gets finalised
before it can run, etc.

So why does this only happen with some versions of gtk+?  Still sounds
like a gtk+/glib bug to me ...

(i.e. you can trigger a destroy of any other object from a signal from
that object).


On Thu, 2005-07-07 at 20:22 +0530, Arunprakash wrote:
> Hi all,
> 
> I have a crude fix for bug #307794.
> I have attached the patch.
> 
> When you select any item from the "Server Type"
> combo box, it emits the "changed" signal.
> 
> This invokes "emae_provider_changed" callback which in
> its execution path calls ec_rebuild.
> 
> Here the page containing the combox box
> is destroyed and a new page with items
> specific for that selected server type
> is loaded.
> 
> But the code in gtkcombobox.c requires
> that combo box for its pending opertions
> and is destroyed in the callback.
> 
> The same happens for the combo box in the sending page also.
> Because the same callback is used.
> 
> My fix removes that widget destruction leaving a memory leak.
> 
> The combo box has to be hold and destroyed later. But how?
> 
> Please review it,
> and give suggestions and comments.
> 
> Thanks,
> Arunprakash.
> 
> _______________________________________________
> evolution-patches mailing list
> evolution-patches lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-patches