Hey Miller,
So I guess the part I don't get is which x->gl_editor should a GOP have? A non-GOP abstraction that is not vised has no gl_editor, while a GOP abstractions/subpatch that is not vised does have a gl_editor of its own (i.e. the GOP has a gl_editor different from its parent when not vised). For some reason, it seems to me that this non-vised GOP should have the gl_editor of its parent.
.hc
On Jan 19, 2010, at 10:26 PM, Miller Puckette wrote:
Well, canvas_findrtext is expected always to succeed, and in order for it to succeed there has to be an 'editor'. Anyway, line 900 checked that there is indeed an 'editor' which means that 'if (!gl->gl_editor) ' is false so canvas_create_editor(gl) doesn't get called (I think).
Anyhow, this is the second most complicated bit in Pd (the worst is canvas_deseltext()) and very, very hard to get working right.
cheers M
On Tue, Jan 19, 2010 at 07:15:16PM -0500, Hans-Christoph Steiner wrote:
Ok, more info on this solo thread. So it turns out that canvas_destroy_editor() calls glist_findrtext() which in turn calls canvas_create_editor(). That doesn't seem to make a lot of sense. It seems that canvas_create_editor() should not be in glist_findrtext().
g_editor.c: 896 void canvas_destroy_editor(t_glist *x) 897 { 898 t_gobj *y; 899 t_object *ob; 900 if (x->gl_editor) 901 { 902 for (y = x->gl_list; y; y = y->g_next) 903 if (ob = pd_checkobject(&y->g_pd)) 904 rtext_free(glist_findrtext(x, ob)); 905 editor_free(x->gl_editor, x); 906 x->gl_editor = 0; 907 } 908 }
g_rtext.c: 355 /* find the rtext that goes with a text item */ 356 t_rtext *glist_findrtext(t_glist *gl, t_text *who) 357 { 358 t_rtext *x; 359 if (!gl->gl_editor) 360 canvas_create_editor(gl); 361 for (x = gl->gl_editor->e_rtext; x && x->x_text != who; x = x->x_next) 362 ; 363 if (!x) bug("glist_findrtext"); 364 return (x); 365 }
.hc
On Jan 19, 2010, at 5:54 PM, Hans-Christoph Steiner wrote:
I've been trying to figure out the whole t_editor/x->gl_editor thing. I've been writing things up here: http://wiki.puredata.info/en/t_editor
It seems to me that there are lots of GOP bugs related to the fact that GOP glists now get a gl_editor assigned to them even when they are not [vis 1(. From what I can tell, there are lots of tests like if (x->gl_editor) which assume that the canvas/glist x -
gl_havewindow==1 if x->gl_editor == 1, which is no longer the case
as of 0.42.
canvas_create_editor was added to glist_findrtext() in this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=...
.hc
On Jan 15, 2010, at 5:13 PM, Hans-Christoph Steiner wrote:
so I guess here is my question, is this how things are supposed to work in terms of GOP:
- when a GOP is drawn on the parent, gl_editor should be the same
as the parent's gl_editor
- when GOP is opened up, it gets its own gl_editor
.hc
On Jan 15, 2010, at 4:44 PM, Hans-Christoph Steiner wrote:
I am trying to debug various issues with GOP and parent/child relationships. I am not quite clear on what x->gl_editor is supposed to be. Can anyone clue me in? The bug seems to be related to the fact that in canvas_vis(), pd doesn't quite know what x->gl_editor is supposed to be, since it changes....
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs