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
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
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
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.
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
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
i _think_ the gl_editor should be the GOP's own, not that of its parent. It's a structure parallel to that of the canvas itself, which supplies "rtext" memory space for each 'text' box in the canvas's gl_list list.
cheers M On Tue, Jan 19, 2010 at 11:03:23PM -0500, Hans-Christoph Steiner wrote:
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
Ok, that makes sense. I've noticed in the code it seems there are some places where a test for x->gl_editor assumes x->gl_havewindow is true. That used to be the case, but no more if non-vised GOPs have a gl_editor.
.hc
On Jan 20, 2010, at 12:27 AM, Miller Puckette wrote:
i _think_ the gl_editor should be the GOP's own, not that of its parent. It's a structure parallel to that of the canvas itself, which supplies "rtext" memory space for each 'text' box in the canvas's gl_list list.
cheers M On Tue, Jan 19, 2010 at 11:03:23PM -0500, Hans-Christoph Steiner wrote:
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
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Ok, another lead, in g_editor.c, for canvas_vis(x, 0), this gets triggered:
if (!x->gl_havewindow) { /* bug workaround -- a graph in a visible patch gets "invised" when the patch is closed, and must lose the editor here. It's probably not the natural place to do this. Other cases like subpatches fall here too but don'd need the editor freed, so we check if it exists. */ if (x->gl_editor) canvas_destroy_editor(x); return; }
A non-vised GOP now will have a x->gl_editor even though it doesn't have its own window. But if it receives a [vis 0(, then that non- vised GOP will have its gl_editor deleted. That doesn't seem quite right, right?
.hc
On Jan 20, 2010, at 11:09 AM, Hans-Christoph Steiner wrote:
Ok, that makes sense. I've noticed in the code it seems there are some places where a test for x->gl_editor assumes x->gl_havewindow is true. That used to be the case, but no more if non-vised GOPs have a gl_editor.
.hc
On Jan 20, 2010, at 12:27 AM, Miller Puckette wrote:
i _think_ the gl_editor should be the GOP's own, not that of its parent. It's a structure parallel to that of the canvas itself, which supplies "rtext" memory space for each 'text' box in the canvas's gl_list list.
cheers M On Tue, Jan 19, 2010 at 11:03:23PM -0500, Hans-Christoph Steiner wrote:
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
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
----------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
-
Hans-Christoph Steiner -
Miller Puckette