Personally, I'm hoping to put band-aids on as many manaifestations of the problem as I can track down (so thanks for this one :) and then re-design the whole editor creation and destruction strategy for 0.44 - it looks like it can never be fully debugged the way it's stet up now!
Miller
On Thu, Dec 15, 2011 at 03:18:30AM +0100, Krzysztof Czaja wrote:
On 12/15/2011 12:10 AM, Ivica Ico Bukvic wrote: ...
Wow! You just helped me finally solve this riddle! Could it be really this simple? In canvas_free() call inside g_canvas.c simply add the following 2 lines:
if (x->gl_editor) canvas_destroy_editor(x);
I added them right below
if (x == glist_getcanvas(x)) canvas_vis(x, 0);Now even if the canvas is recreated with the same memory space there is no more double-entry bug. Are there any potential regressions with this model? The canvas is getting freed so I cannot imagine this posing any problems but then again I am sure I may be missing something...
this only handles the case when the GOP is part of a toplevel window.
The other case is when the GOP's parent isn't toplevel. When the window of such a parent is closed, the canvases themselves aren't destroyed, but the editors should be.
So I think the best way is to get rid of sub-editors recursively. I may be mistaken, though, because there are some partial workarounds already in the code. Apparently, Miller had been aware of the issue but then things went their own way, somehow.
Krzysztof
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev