I don't remember why it's there (and perhaps it's no longer necessary) - but I suspect it had something to do with a subtle problem when deleting a GOP whose interior got mad wieh there was no rtext for the owning object.
The rtext eventualy goes away when the window is closed - but perhaps it's a problem if there's a self-editing patch that creates and deletes 1000s of objects in an open window? cheers Miller On Mon, Feb 25, 2013 at 10:36:46PM -0500, Ivica Ico Bukvic wrote: > Does anyone know why does the following exist inside the > glist_delete function inside g_graph.c: > > /* if we're a drawing command, erase all scalars now, > before deleting > it; we'll redraw them once it's deleted below. */ > if (drawcommand) > canvas_redrawallfortemplate(template_findbyname(canvas_makebindsym( > glist_getcanvas(x)->gl_name)), 2); > if (glist_isvisible(canvas)) > gobj_vis(y, x, 0); > --> if (x->gl_editor && (ob = pd_checkobject(&y->g_pd))) > --> rtext_new(x, ob); > if (x->gl_list == y) { > > That rtext is never freed after that so unless I am missing > something I see no reason why we would want to do this. Any ideas? > > -- > Ivica Ico Bukvic, D.M.A > Composition, Music Technology > Director, DISIS Interactive Sound & Intermedia Studio > Director, L2Ork Linux Laptop Orchestra > Head, ICAT IMPACT Studio > Virginia Tech > Department of Music > Blacksburg, VA 24061-0240 > (540) 231-6139 > (540) 231-5034 (fax) > disis.music.vt.edu > l2ork.music.vt.edu > ico.bukvic.net > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev