[PD-dev] what does x->gl_editor represent?

[Miller Puckette]

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=10469
> >>>
> >>>.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 at 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